franckpachot

Or how to transform the open-source, no-vendor community PostgreSQL into a proprietary database, where each managed service comes with its own unique syntax, features, and benchmark claims. People go to PostgreSQL for freedom, not to bind their application to one extension with one owner and one maintainer.

And:

> The instance was assigned a public IP

I think that without a private link, the managed services that run in different accounts (Neon, Crunchy, Clickhouse if not BYOL) may be in a different data center than the client's. And this is just default pgbench where most of the time is spent on client-server roundtrips

"dollar quoting" is the PostgreSQL way to quote strings with quotes, avoiding double quoting or escape characters. I like to use the tagged version of it, like $sql$ SELECT ... $sql$ to describe what is inside.

CloudNativePG is automation around PostgreSQL, not "batteries included", and not the idea of Kubernetes where pods can die or spawn without impacting the availability. Unfortunately, naming it Cloud Native doesn't transform a monolithic database to an elastic cluster

It's largely cultural. In the SQL world, people are used to accepting the absence of real HA (resilience to failure, where transactions continue without interruption) and instead rely on fast DR (stop the service, recover, check for data loss, start the service). In practice, this means that all connections are rolled back, clients must reconnect to a replica known to be in synchronous commit, and everything restarts with a cold cache.

Yet they still call it HA because there's nothing else. Even a planned shutdown of the primary to patch the OS results in downtime, as all connections are terminated. The situation is even worse for major database upgrades: stop the application, upgrade the database, deploy a new release of the app because some features are not compatible between versions, test, re-analyze the tables, reopen the database, and only then can users resume work.

Everything in SQL/RDBMS was thought for a single-node instance, not including replicas. It's not HA because there can be only one read-write instance at a time. They even claim to be more ACID than MongoDB, but the ACID properties are guaranteed only on a single node.

One exception is Oracle RAC, but PostgreSQL has nothing like that. Some forks, like YugabyteDB, provide real HA with most PostgreSQL features.

About the hype: many applications that run on PostgreSQL accept hours of downtime, planned or unplanned. Those who run larger, more critical applications on PostgreSQL are big companies with many expert DBAs who can handle the complexity of database automation. And use logical replication for upgrades. But no solution offers both low operational complexity and high availability that can be comparable to MongoDB

What about "cannot scale without downtime"? While all databases can scale vertically, increasing or decreasing CPU or memory resources requires a restart, which leads to downtime. All sessions must disconnect, the system restarts, and users reconnect and execute their first queries with a cold cache. This is far from ideal, especially when workload spikes—the very situation where scaling up is needed. Cloud-native databases that promote scalability typically scale horizontally without downtime. This involves adding or removing nodes and automatically resharding data without stopping the application. Such elasticity is key to the cost efficiency in the cloud: it lets you scale resources up or down with the workload, avoiding excess provisioning.

What is the null join behavior that cause you problem?