I'd summarize the replication story of postgres to be: "harder to use but easier to understand". PostgreSQL generally builds things from the bottom up -- first

I'd summarize the replication story of postgres to be: "harder to use but easier to understand". PostgreSQL generally builds things from the bottom up -- first working really hard to get the fundamental infrastructure right, and then the utility starts falling into place. This has a few advantages: * The fundamental infrastructure tends to be more general, so many different functional improvements come out quickly after the infrastructure is in place. * It forces everyone involved to think through the edge cases first, leading to a more robust feature and a better-tested feature. * When things go wrong, all of the parts make more sense individually, so it's easier to understand what happened and fix it. * Eventually, the usability issues are addressed in a way that's not dependent on a lot of black magic. Anecdotally, when things go wrong in $MAGICALLY_REPLICATING_DB, they tend to go very wrong, very fast. I am skeptical by nature, so I generally assume that $MAGICALLY_REPLICATING_DB glosses over a lot of the finer points, which don't get exercised in a normal testing environment. I haven't presented any facts here, so you may disagree. A lot of people share my skepticism, and are willing to put up with a few rough edges in the usability as long as the pieces make sense and they feel they can understand and trust them. I was at a presentation by Instagram, and replication was one of the primary reasons they went with postgres. They used a tiny engineering team (one and a half engineers working on the database) to scale to tens of millions of active users (also using sharding; another thing that is harder to use but easier to understand in postgres).