3 ms·

As someone who took a stab at automating slony deployment and configuration, I have to agree that the replication situation is not quite there yet. There are ma

As someone who took a stab at automating slony deployment and configuration, I have to agree that the replication situation is not quite there yet. There are maybe 2-3 examples online on how to use some of those tools, and maybe half a dozen people who actually would be able to answer questions about them. Betting your business's scaling future on that kind of tooling is terrifying. Would be great to have both out of the box failover (you can get that in RDS nowadays) and logical replication. I suppose the latter can stave off the need for sharding for a while. I believe there's work happening for UDR/BDR right now that will be in the product by 9.5 or 9.6

tracker1 11y ago
You can go a long way with read-only replication, as long as you have a good failover strategy for writes before you need sharding... The only time you really need sharding is once either your reads or writes require more than a single system in you cluster could keep up with in terms of requests. That said, using something like RethinkDB (not sql) from the start isn't a bad thing... And depending on your needs Cassandra, ElasticSearch and others are viable options... beyond that there's no need to stick with a single database for different types of data. It should be a case by case basis. As to the comments about Postgres replciation/failover, it's a pretty sad state imho for an otherwise very respectible database.