I think it's a significant danger.

But on the other hand our current table storage has some architectural issues that are hard to fix in an upward compatible manner (causing a number of issues around vacuum and write amplification due to hint bits etc). And even if there were an easy-ish incremental upgrade path, it's hard to e.g. move to an UNDO based MVCC implementation without regressing some workload (& introduce bugs) - allowing that development to happen in parallel and the adoption be by choice, that's much more realistic.

Additionally, the best type of table storage is also very workload dependent. E.g. for some analytics (or even just long term storage) it's quite useful to have a columnar store, but for lots of transactional workloads that's not appropriate. (Note that the current tableam interface would allow for some simple columnar store, but that'd still need a good bit of planner and executor smarts to be useful for anything but higher storage density.)

So I think on balance it's probably worth it.

From my perspective, columnar storage is an enormous win. One of the best things I've been able to do for clients on MSSQL has been to tell them simply to create a clustered columnstore index on their large tables for analytical workloads.

At one point we had a need to perform a diff between a yesterday-snapshot and a today-snapshot of a billion row table. If I recall correctly, this took 1 or 2 minutes with clustered columnstore vs nearly an hour for rowstore. The order of magnitude is certainly correct, even if my specific numbers are wrong.

If you're curious why we had to do a full diff between two billion-row tables, that is a story for a different time, but there were good reasons and we also removed those good reasons through other design decisions.

MySQL's situation, as it has been for years, is:

1. Almost everyone uses InnoDB (or whatever the forks call it)

2. Customers who need to use other engines can do so if it makes sense for them

3. Tuning is basically always the same unless you're doing something extremely atypical (e.g. using TokuDB)

There's no fragmentation there in any real sense.

I doubt it will fragment the ecosystem at all. Plugins such as PostGIS have been widely adopted by people who need it for years, and has fragmented nothing. Others end up integrated into core. If you have specialized storage requirements, you no longer need to fork, and that means less fragmentation of the ecosystem.

given that postgres is free as in beer, i think in practice this just means the definition of less flexible and more polished tiers, up to and including db-as-a-service.

this seems like a nice model - more useful than the tens or hundreds of functionally equivalent linux distributions. you can start out with generic turnkey postgres-lite and unwrap as much as you like.

that said, despite quite a bit of progress in the last few years, postgres-lite could be easier to install and maintain.

> given that postgres is free as in beer

Postgres is free-as-in-speech.

Free-as-in-beer refers to free-of-charge, proprietary licensed software (e.g., SQL Server Express), not software under a permissive free software license.