Just saw this now, I do wish HN had a proper notification feature...

> That postgres is behind in scaling (multi-core, replication, sharding, multi-master) against all modern relational databases is verifiable truth.

No, it's really not. It's hardly best of class in them, but the worst? Meh. That's just my point, you're making way to strong statements.

Just to start at your first point: multi-core. Mysql has just about no intra query parallelism, whereas postgres 9.6 has some limited support, and postgres 10 is decent, although far from great. Postgres' inter query parallelism was for a long while better than mysql, then mysql was better for a couple years, in the last couple years it's gone back and forth and depends on the specific use-case. So how is postgres verifyably worse than all other "modern" (whatever that means) relational databases?

> Your judgement is clouded by your proximity to the project.

That's quite possible.

> Here's just 1 prior thread between us: https://news.ycombinator.com/item?id=13841496

I do remember that, but there you're again arguing super reductionist. You're arguing that having to do

CREATE PUBLICATION all_tables FOR ALL TABLES;

before subscribing to replication somehow makes logical replication fundamentally too complicated ("overbuilt mess").

Yes, the logical replication stuff has some serious limitations, and that's true. A significant subset already has patches out there for the next version, but that doesn't help current users.

The streaming replication support existing since 9.0 is pretty decent however, and has gotten a lot easier to use in the last releases, and especially with the saner defaults in v10.

> Add (and enable) multi-core queries.

There's some massive progress in v10.

> Build-in pgbouncer (or better connection management).

Indeed.

> Enable 1-line command to setup basic replication (whole node or per db level) without having to edit anything else. Look at redis or memsql for inspiration.

It's two commands for both physical and logical replication now. Not perfect, but not too bad either.

> Add DDL support to logical replication because I guarantee this will be the #1 source of problems for anyone that tries to use this.

Yup, I've argued just that point, and I've implemented it in a precursor of what's now in core for logical replication. I sure hope that's going to largely get into v11.

> Enable 1-line command to easily failover, remove hotstandby requirements.

Not sure what you mean with "hotstandby requirements"? The defaults? Those have been fixed in v10. Not being able to do certain things on a standby?

> Fix the poor defaults in all the configs.

We're making some progress, e.g. that everything's now by default ready to streaming replication, but there's a lot more to do. It's sometimes hard because the many different usecases ask for different defaults.

> Solid in-cluster and cross-dc replication is the reason we stuck with memsql (+ built-in columnstore)

What specifically are you seeing lacking w/ cross-dc replication? I completely agree that there's UX/complexity issues around replication, but I don't see how those affect cross-dc specifically? There's plenty of people quite happily using cross-dc replication, once it's set up.

> I've shared all of this feedback online over the years (along with many others) so the lack of understanding is really more a reflection of the postgres team and poor priority planning.

Or perhaps also a question of funding, time and communication style.