People who cite the CAP theorem as the reason they went with MongoDB etc for their tiny new project deserve some kind of premature optimization medal. The CAP t

People who cite the CAP theorem as the reason they went with MongoDB etc for their tiny new project deserve some kind of premature optimization medal. The CAP theorem starts to matter when you are dealing with highly distributed systems, and even then there is almost certainly a long series of simpler workarounds to keep things usable than redoing your data architecture. Some downtime, too, is of course undesirable but acceptable up to a certain point, which is also something people tend to gloss over when raising concerns about CAP. The biggest hangup other than the UX issues the author talks about is the fear of having to manually shard your data. There are a lot of promises about automatically sharding your data from NoSQL vendors but I have no idea if they actually are able to deliver on this. If you are just doing a K-V store, then of course sharding is easy, regardless of the database you are using. I don't think there is really a silver bullet here, just maybe better tooling and removing redundant manual steps. You still need to think carefully about data access paths and queries and so on. Any additional sharding-centric features of NoSQL databases missing in mainstream databases could presumably be added, if they don't exist already with poor UX. For example PostgreSQL replication, wal log archiving, etc works great but it's still a bit tougher to set up than the more magical cluster auto discovery/configuration/sync stuff you see in things like elasticsearch. It would be interesting if the PostgreSQL people made a real push for a release to tighten up the operational UX of the product to be more human friendly instead of adding on more core features. (Not that I'm complaining, it's great!)