9 ms·
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-
by whitepoplar 4y ago
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.
- morrbo 4y agoNever agreed with something so much more in my life. Points 1-3 in particular. I understand their logic of not wanting to "pollute" the core products with these features.... but it's sort of past the point now where you're starting to expect this stuff in a modern database product (instead of add-ons, hacks, and outdated blog posts)
- seedless-sensat 4y agoPoints 1-3 exactly describe my pains operating Postgres at scale
- threeseed 4y agoIt is kind of ridiculous that the first three haven't been sorted by now. 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.
- LtWorf 4y agoWhat would the proprietary vendors sell then?
- ahachete 4y ago> 2) Horizontal scalability without having to resort to an extension like Citus. 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?
- threeseed 4y agoIt means that when you upgrade PostgreSQL you don't have to worry if the extensions are compatible and have been fully tested not just for functionality but security etc as well. 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.
- ahachete 4y agoRight, those are compulsory steps for every upgrade. 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)
- Keyframe 4y agoCitus is Microsoft for quite awhile now. Take what you will from that.
- threeseed 4y agoThe "you can always fork Citus" argument is not workable. 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.
- ahachete 4y agoSharding databases is not such a dark, magic art. Citus relies on Postgres for many key features; and Citus does the rest. It's already quite "feature complete". 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).
- viraptor 4y agoWhat do you mean by query pinning? Something like query cache where the results are kept around explicitly?
- whitepoplar 4y agoSorry, query plan pinning.
- gavinray 4y agoIt's not baked-in, but Andy Pavlo has an ML-based tuning tool called "Ottertune" for Postgres: I think it's free for a single DB https://ottertune.com/ https://ottertune.com/
- tbillington 4y agoOnly for instances on aws though.
- ies7 4y agoWe've used postgres for so long that number 1 & 3 feels just automatic for our teams to setup and don't ask why they're not built-in in postgres.
- ksec 4y agoIt is funny to see this because every time these reasons for people continue to use MySQL are listed, PostgreSQL folks will be quick to reply most of these are non-issues.
- KyeRussell 4y agoThis sort of tribal framing doesn’t do anything to help the situation. I’m immediately willing to believe that the “Postgres folks” that are saying that, genuinely have not found these points to be issues, which doesn’t mean that OP doesn’t.
- qazxcvbnm 4y agoFor 4) I've heard there's this available https://github.com/DrPostgres/pg_plan_guarantee https://github.com/DrPostgres/pg_plan_guarantee
- avinassh 4y agoHow does Citus provide horizontal scaling? How does it work?
- EamonnMR 4y agoBig second on horizontal scaling. Amazon Redshift is a great example of what's possible, but it also has enough problems that you can't really use it as a primary application database.
- zX41ZdbW 4y agoRedshift is an OLAP database, much like ClickHouse. For OLAP databases, horizontal scalability is a must - due to generally larger data volumes. While Postgres is OLTP. For OLTP databases achieving horizontal scalability require a more sophisticated approach to distributed consensus, like in CockroachDB or Spanner.
- _448 4y ago> Horizontal scalability without having to resort to an extension like Citus. 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.
- Existenceblinks 4y agoI would love 6) unique constraints across all partitions
- boiler_up800 4y agoYugabyte delivers most of these. It’s also the “purest” implantation. I expect it to be the winner over time of the Postgres scaling wars.