I'd love to see:
1) Simple, easy to use, high-availability features.
2) Horizontal scalability without having to resort to an extension like Citus.
3) Built-in connection pooler.
4) Query pinning.
5) Good auto-tuning capability.
1) Simple, easy to use, high-availability features.
2) Horizontal scalability without having to resort to an extension like Citus.
3) Built-in connection pooler.
4) Query pinning.
5) Good auto-tuning capability.
And over time it will increasingly relegate PostgreSQL to being for development only with production use being handled by wire-compatible databases e.g. Aurora.
I think it's free for a single DB
Just curious, what would save you having the solution in-core? Installation, sure, but that's a one-off possibly in your deployment code. "CREATE EXTENSION citus" and add that to postgresql.conf? Sure, but not too much work for me. The rest (commands to actually create the nodes, do the sharding itself) are something I cannot imagine being different or simpler if with an in-core solution.
What am I missing?
And most importantly it means you don't have to worry if that extension will move to a freemium model which (a) often has important features out of your price range and (b) is generally unacceptable in enterprise environments.
Yet in the particular case of Citus, history (so far) has shown a) that they update the extension regularly and fast, so by the time you want to upgrade to a newer major version you already have Citus updated too; b) they are going exactly in the opposite direction of "freemium", they actually open sourced even the previous proprietary bits; c) as OSS, it can always be forked and if one day closed source, being such an important project, it would be definitely forked.
(I don't have any stakes on Citus)
Scaling databases is an expert skill that is far out of reach for almost everyone.
Far easier just to pick another database that includes HA and horizontal scalability out of the box.
If Citus would become proprietary overnight, my main concerns of maintaining a fork would be around the codebase and the language expertise more than the sharding concepts.
Note that sharding is different from a purely distributed database. The latter is an entirely different class (and more complex system).
Citrus also has one glaring problem: single point of failure due to a single monitor node.
Postgres would blow every other database away if it had HA, multi-write nodes and fault tolerant feature similar to FoundationDB or TiDB.
While Postgres is OLTP. For OLTP databases achieving horizontal scalability require a more sophisticated approach to distributed consensus, like in CockroachDB or Spanner.