I manage database clusters where the number of databases is a reason not to do logical replication based upgrades, where pg_upgrade is far preferred instead.
If this were to be the case, I would be very concerned that a bunch of things would have to change:
1. Shared catalogs would have txid problems unless you stay with global txids and then how do local wal streams work there?
2. Possibility that suddenly streaming replication has the possibility of different databases having different amounts of lag
3. Problems with io management on WAL on high throughput systems (I have systems where a db cluster generates 10-20TB of WAL per day)
So I am not at all sure this would be a step in the right direction or worth the work.
I agree these are all technical issues, but nevertheless - "implementation details", which DBAs don't care about. What's important from a DBA's perspective is not whether WAL is cluster-wide or database-wide, but whether it's possible to manage backups/PITR/restores of individual databases in a more convenient matter, which other RDBMS-vendors seem to provide.
I love PG, have been using it professionally since 6.5, and our company depends on it, but there are things other RDBMS-vendors do better...
All,
Since we’re not limited by how many instances of Postgres we run, we actually have a setup where we do live backups over a multi-node configuration. More than one Postgres instance, and syncing between the databases as a scripted process across database instances. This allows us to do some interesting things like replicate to mobile hardware for Postgres in the field, etc.
The difference in how the DBs accomplish things are more related to taking advantage of the capabilities in each software package vs comparing on a function by function basis.
