I've been thinking about this a lot recently, and while I used to unambiguously agree with this, I'm slightly more uncertain now. First, to be sure, in the yea

I've been thinking about this a lot recently, and while I used to unambiguously agree with this, I'm slightly more uncertain now. First, to be sure, in the year of 2017, it's definitely the safe path to go with Postgres or MySQL. Traditional relational databases aren't distributed out of the gate, which is both a good thing and a bad thing. They're mature, which means that lots of bugs have been found and fixed, and there's a Stack Overflow answer for every basically error possible. And yes, Postgres will remain the "best" choice probably for at least another decade. Very broadly, traditional relational databases are chosen because of two advantages: features (rich data model, query language, ACID transactions, etc.), and maturity. NoSQL datastore generally sacrifice the former for the sake of scalability, and lack the latter simply because they're too new. First, the features. I think most people are in agreement that stripping down your data model to fit into a basic but highly scalable key-value store ultimately hurts productivity. But it's definitely not impossible for a scalable distributed database to provide most or all of the features that a traditional relational database provides; that's exactly what Google did[1], and what some open source projects[2] are trying to emulate. Sharding Postgres is safe, but it's also hard. It does messy things to your application code, and also hurts productivity. And at the end of the day, you still don't get ACID transactions and joins if you ever have to do anything that touches more than one shard. We really do need a better solution that combines the best of both worlds. Sure, traditional relational databases will probably always be the most mature databases around. But there will come a time when those new databases are mature enough. And I think along the way, we can rethink some of the properties of traditional SQL that make it hard to work with sometimes. 1: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41344.pdf https://static.googleusercontent.com/media/research.google.c... 2: http://db.cs.cmu.edu/papers/2016/pavlo-newsql-sigmodrec2016.pdf http://db.cs.cmu.edu/papers/2016/pavlo-newsql-sigmodrec2016....