Love the DB federation stuff - so awesome!
[Comment removed by author]
Sharding is harder, database federation helps though. Riak makes it easier to shard, that comes with a ton of tradeoffs. Not that those tradeoffs make Riak bad, but there are still a lot of reasons to use Postgres.
If you don’t want to give up SQL, check out Clustrix (at which I work). It’s MySQL-compatible and distributed, so you don’t have to shard.
It’s funny when RDBMS proponents rack down on NoSQL for not being “durable” or not “being ACID”, when in fact, most RDBMS, including Postgres aren’t either.
I found this presentation to be mostly FUD and misunderstandings about what the things they talked about mean. I’m sure the Postgres things are correct, but the first half of the presentation was mostly misinformation about other ways of storing data. It’s easy to be consistent when there’s only one copy of your data – but to say that something that stores only a single copy of the data is “durable” when one that replicates it is not, then what do you even mean by “durable”?
I’m sure Postgres' HStore and JSON columns are very useful if you’re already using Postgres, and for things where a relational model is useful (on the fly aggregations of small data sets, for example), and Postgres replication story seems to have gotten better lately. I just find it silly and unhelpful to bash NoSQL for things like “not being ACID”, when you include a slide like #24 and say “by the way, if you need better performance, you can turn off that pesky durability, just like those fast NoSQL systems”. Why do you think those NoSQL systems exist in the first place?
to say that something that stores only a single copy of the data is “durable” when one that replicates it is not, then what do you even mean by “durable”?
That’s easily answerable by looking up what durability means in the context of ACID. It means that, once a commit succeeds, the changes are not lost in case of system-level outage.
This slideshow talks about write scalability but leaves out write availability. For something like patient information, write availability is generally more important because if you lose a write people can die. This is really hard to do right in ACID.
Also, I think a single database trying to fulfill almost all your database needs is somewhat dangerous for most organizations. If you have a core group that is really skilled in that database and can help any team run one then it might work, but most organizations don’t have this. A Swiss Army Knife DB is going to be very complicated, with a lot of interesting corner cases, make it operationally very expensive. One value of something like Riak is that the model is very simple. It’s not a model for every use case and that is often very obvious. Purity of purpose can often lead to simplicity overall even if it’s more components.