On databases

In the middle of SQL/NoSQL/NOSQL war it is easy to forget what a database is.

Database is the place where data resides. Note that I am using a definite article here. It’s not “a place”, nor there are such things as databases (plural). All of the work that is done on databases assumes a closed world which is curated and managed centrally. Atomicity, consistency, constraints and triggers are all designed to work in this scenario and this scenario alone. Multiple databases are like parallel universes in the multiverse — their existence is not prohibited, but politely ignored by all but few crackpots.

Since [successful] businesses are dealing with an open world, it was just a matter of time till this closed-world approach broke down. Alternative models were developed (often by being dug out from old archives). “Key-value database” went from being an oxymoron to a household name. Provocative sentiments “your log files are a database”, “your message bus is a database”, “your mouse is a database” are widespread.

It would make sense, then, to take a look at the most successful “key-value database” ever. I am talking, of course, of the DNS. It’s federated, extremely highly available, easily shardable, has a lightweight and extensible schema and also manages to be vendor-neutral. Still, it is only being called a “database” in metaphorical sense. It is this understanding that DNS deals with an open world that makes it so successful and so not database-like. In a sense, the “base” part of the word becomes unnecessary, confusing and harmful.

The database is dead. Long live the data.