4 ms·
> It's always been feature-weak compared to PostgresQL For many years MySQL had a much clearer multi-master replication story than PostgresQL. For most use cas
by ericb 8y ago
> It's always been feature-weak compared to PostgresQL
For many years MySQL had a much clearer multi-master replication story than PostgresQL. For most use cases, other features are secondary to replication.
- CWuestefeld 8y agoFor most use cases, other features are secondary to replication. I'd say the opposite - for most use cases, replication doesn't even figure into it. I guess we both need to find more solid evidence than our own opinions.
- ericb 8y agoI suppose if you reason from some other criteria than avoiding downtime and data loss, a different conclusion was possible at the time. To each their own.
- CWuestefeld 8y agoReplication is not the best way to avoid data loss. And it's not the only way to avoid downtime (e.g., the AWS Aurora PostgreSQL servers I run don't use the normal pg replication). And there are a lot of systems for which downtime really is acceptable, at least for the amount of time it takes to restore a backup. Not everything is a front-end, mission critical system. I manage plenty of systems that are only used in a back-end batch context. So I think it's crazy to suggest that how well a db engine's replication work outweighs all other factors. Depending on your situation it may well be the most important thing, but there's a lot of room for others to have well-architected systems that have different priorities.