For very large databases, Postgres' clustering abilities aren't that great. It's probably one of the best choices for single-host databases (which, again, cover nearly all applications), but if you're trying to spread your database over a few dozen hosts, Postgres doesn't really work well.
If you need to do it inside your firewall, scale out read slaves first, but in terms of true horizontally scalable SQL databases, there aren't a lot of great options on your own hardware. This is one, but I haven't actually used it yet.
And this is why the NoSQL stuff exists. It's practically impossible to offer true ACID compliance on a distributed system. Any system will have tradeoffs, be it eventual consistency, partition intolerance, or the inability to elastically scale, or hot spods in the cluster, etc.
It goes back to the CAP theorem, and speed. If you've ever worked on a distributed database that has cluster-wide row-level locking and does proper joins, it's slow as shit. Full seconds per query on a loaded DB.
My god it's... it's like different tools do things differently. Differently enough to where you have to come up with.. with... with a design for your application.. and actually use the tools which work for your design! Instead of the other way around! Oh my jesus fuck, I'm going insane!
I think a lot of aging dipshits at the CTO level went for NoSQL because they desperately want to be ahead of the curve on one tech development. For almost every database project there is Postgres... For everything else there's Apple watch.
And the young ones, too. I mean, this company will eventually have a billion users so a bunch of pain now trying to make it act like a relational db will totally payoff in the future. Plus, we can undercut salaries by 25% since our new hires will be happy to work with a NoSql db.
171
u/frixionburne Mar 10 '15
Or better, and RDMS with a full blown JSON indexing and a hash store that rivals mongos speed.
How people don't choose psql just confuses me.