A flat document storage engine calling itself a database? On any other day, that’s what you’ll get from a collaboration between a vendor and PR agency, pushing new ways to achieve synergy and optimize the bottom line to Global 5000 companies.
This day, it happens to be CouchDB. And CouchDB on first look seems like the future of database without the weight that is SQL and write consistency.
It stores document in a flat space.
There are no schemas. But you do store (and retrieve) JSON objects. Cool kids rejoice.
And all this happens using Real REST (you know, the one with PUT, DELETE and no envelopes to hide stuff), so it doesn’t matter that CouchDB is implemented in Erlang. (In fact, Erlang is a feature)
Here’s where it gets interesting. There are no indexes. So your first option is knowing the name of the document you want to retrieve. The second is referencing it from another document. And remember, it’s JSON in/JSON out, with REST access all around, so relative URLs and you’re fine.
Here’s the kicker. This simple architecture you can partition and replicate any way you want, map/reduce these computed tables on any scale, and deal with the rest on the client.
And if you’re using a sane person’s programming language, it’s a trivial matter.
I’m personally convinced that write consistency is the reason RDBMS are imploding under their own weight. Features like referential integrity, constraints and atomic updates are really important in the client-server world, but irrelevant in a world of services.
You can do all of that in the service. And you can do better if you replace write consistency with read consistency, making allowances for asynchronous updates, and using functional programming in your code instead of delegating to SQL.
It’s an incredibly hard problem to solve in languages like C or Java, but we’re past that stage, and it’s time to start looking beyond SQL.
So CouchDB is still an alpha, but a serious project to look at.
Update: For more context: Read Consistency: Dumb Databases, Smart Services