Sam is always shitting on others. For years he has been screaming how bad PostgreSQL is compared to MySQL. Until getting silent about this topic for a few months and then launching PostgreSQL support. Seems he had to realize than the market for PostgreSQL is too big to ignore.
And there is no single company developing. Its a healthy mix of engineers from many companies. A perfect model to prevent this issue here of being aquihired.
The article suggested using TimescaleDB which has its own concept of IVM: continuos aggregates. And compared to the approach by ClickHouse it can also update the materialized views when you update/delete old raw data
Yes but that is just one use case. Columnar OLAP engines operating on object storage can do all kinds of stuff so much better than Postgres that it may as well be a completely different capability. That said - the point is that you can get a lot further with just Postgres than many people think, and now we also have options like pg_lake. But I wish I'd changed analytics platforms A LOT sooner than I did.
I’m sort of amazing that nothing in that thread mentioned ClickHouse, even just as a product that has this capability and from which one might take syntactical inspiration.
The question is more what this really solves. They said they built all this because DNS propagation was too slow. But secondary dns servers by e.g. your isp will still have old records when you change something. So what did they earn? Every is correct within their network pretty fast. But for a normal user there isnt any difference because 8.8.8.8 or 1.1.1.1 still cache old records?
Looked it up, says 'Will be released as an open source project' but announcement was in July 2025 and no public repo yet which is strange, so time will tell if they will stick to this.
We are already moving Neki customers into production. Nobody else is even close. PlanetScale doesn't spend our days yapping about what we are going to do. We just do it.
I was thinking of something that only exists at the pool level.
Every new version of your app has the potential to change behavior in a way that would affect the previous version if the connection was recycled during a progressive rollout.
But I don’t think I would want to create a real database user for every version of the app.
I suppose the connection pooler could map versioned users to the same real user, and use separate pools, but a dedicated UA field is probably better.
reply