4 ms·
> No it's not. Postgres barely has decent replication as is. You're overly negative whenever postgres comes up on HN. Obviously the v10 stuff is not multi-mas
by anarazel 9y ago
> No it's not. Postgres barely has decent replication as is.
You're overly negative whenever postgres comes up on HN. Obviously the v10 stuff is not multi-master and the project definitely is not claiming it has, but saying that Postgres' replication "barely has decent replication as is" is a bit absurd given that it works quite well in a lot of high-throughput scenarios in a lot of companies, and has so for 5+ years. There's a lot of valid complaints about it you can make (especially around flexibility and operational issues), but it's definitely not just "barely decent".
I'm not saying that you have to be fan. It's fine to say the replication isn't good enough for everything, or just ignore postgres.
> but nowhere near what it takes for multi-master replication.
FWIW, there's async MM built on top of the relevant pieces, and it's used in production. It's not ready for wide audiences, but arguably (and I think one can very validly disagree about that) it's closer than "nowhere near".
- anarazel 9y agohttps://news.ycombinator.com/item?id=14578213 https://news.ycombinator.com/item?id=14578213 https://news.ycombinator.com/item?id=14373424 https://news.ycombinator.com/item?id=14373424 https://news.ycombinator.com/item?id=13653708 https://news.ycombinator.com/item?id=13653708 https://news.ycombinator.com/item?id=13423951 https://news.ycombinator.com/item?id=13423951 ...
- manigandham 9y agoWhat is the point of this comment? And then linking to my past comments? Is it wrong to have perspective and criticism or to express it multiple times? I get that you're a committer but "overly negative" is as much your opinion as what I say, and my comments are the truth as I see it. I've even spent an hour talking to Ozgun about databases and moving to Citus before so my statements come from being a user, operator and maintainer of dozens of different database technologies in production for years, including postgres right now, and from all that experience it is definitely the most behind when it comes to replication/HA compared to anything else I use. All of those threads have plenty of upvotes and other user comments so it's clear I don't stand alone here. Perhaps instead of policing my statements, time would be better spent on improving the features and experience of the product.
- anarazel 9y ago> What is the point of this comment? To let you know that I find your comments overly negative, and that they might have a bigger impact if formulated in a bit more relative manner? I mean: > Postgres is probably the weakest of all relational databases when it comes to scalability, both vertical and horizontal. Doesn't strike me as a particularly useful comment, given the (to me) obvious hyperbole. If you'd instead, at least every now and then, explain what precisely you find lacking, people - like me - could actually draw useful conclusions. I only said something because I remembered your name from a couple times reading quite negative and undifferentiated comments. And I linked to the comments because I searched for them to validate whether my memory of the past comments was/is correct. > Perhaps instead of policing my statements, time would be better spent on improving the features and experience of the product. I do that. Just about every day.
- manigandham 9y agoThat postgres is behind in scaling (multi-core, replication, sharding, multi-master) against all modern relational databases is verifiable truth. Your judgement is clouded by your proximity to the project. Here's just 1 prior thread between us: https://news.ycombinator.com/item?id=13841496 https://news.ycombinator.com/item?id=13841496 And if you want more feedback: -> Add (and enable) multi-core queries. -> Build-in pgbouncer (or better connection management). -> 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. -> Enable 1-line command to easily failover, remove hotstandby requirements. -> Add DDL support to logical replication because I guarantee this will be the #1 source of problems for anyone that tries to use this. -> Fix the poor defaults in all the configs. -> Document the existence of pg_conftool and make it a first-class tool that can also edit pg_hba.conf automatically so I no longer have to deal with any config files. Store any other settings in the database cluster itself. Inspiration from sql server on linux or cockroachdb here. IT/admin UX at this point is more important than the diminishing core upgrades. Postgres is good enough internally but has sorely fallen behind on usability with obsolete defaults, convoluted configs and way too many 3rd party tools needed for basic scaling. Saying use X tool is effectively the same as just use Y database that already does it. MySQL, MariaDB, even SQL Server are not standing still. Solid in-cluster and cross-dc replication is the reason we stuck with memsql (+ built-in columnstore), not because it was possible but because it actually works easily and reliably with their fantastic memsql ops program. 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.