Almost five years ago, we were witness to the reinvention of web frameworks. A couple upstarts named Django and Rails appeared at almost the same time, espousing many of the same values. In the typical Gandhi-cycle, they were first ignored, the incumbents fought them, and then they achieved victory over the incumbents. Today, any framework that’s used on new projects is likely to have more than a hint of Django and Rails in it.
Today, we’re seeing the same thing for databases. Something is going on and things are changing. Barring an unprecedented departure of fashion from software development, I’ll look back five years from now and write about some other shift in the development landscape.
But, all shifts like this need a name. Right now, the best we have is NoSQL. The problem with that name is that it only defines what it is not. That makes it confrontational and not amazingly particular to what it includes or excludes.
Damien Katz, the creator of CouchDB, has noted the need for a better name for this storage revolution. Allow me to proffer mine:
Post-relational
What we’re seeing its the end of the assumption that valuable data should go in some kind of relational database. The end of the assumption that SQL and ACID are the only tools for solving our problems. The end of the viability of master/slave scaling. The end of weaving the relational model through our application code.
We’re seeing an explosion in the ideas about how one should store important data. We’re looking at data to see if it’s even worth persisting. We’re experimenting with new semantics around structure, consistency and concurrency.
In the same way that post-modernism is about reconsidering the ways of the past in art and architecture, post-relational is a chance for software developers to reconsider our own ways. Just as post-modernism didn’t invalidate the entire history of art, post-relational won’t invalidate the usefulness of relational databases.
However, it’s likely that those working in some domains will decide that non-relational databases better fit their needs. That’s progress in our field. It’s fun to watch.
Say it with me: post-relational databases, post-relational storage, post-relational thinking, or simply, post-relational.
Adam Keys is typing 
To the NoSQL crowd navigational models are post-relational.
To everyone else they are pre-relational.
You’ve blown my mind ;) Could you expand on navigational models?
http://www.c2.com/cgi/wiki?NavigationalDatabase
http://blogs.conchango.com/davidportas/archive/2009/08/18/the-relational-model-turns-40.aspx
Ahhh, indeed. Everything old is new again. It’s why humankind developed durable storage.
I like post-relational, but it still defines the ideas using a negative. What is it? It isn’t relational, or it is after relational. Still, I’d be happier with post-relational.
Tim, I think you make a valid point. Post-relational is perhaps only incrementally better than NoSQL in that it isn’t confrontational and better captures the essence of the shift we’re undergoing. I hope it’s better than incremental, but only time can tell.
I think it’s going to be hard to what this shift _is_ for a while. Right now it’s key-value stores and document databases. Master-slave replication/scaling and masterless scaling. No query language all the way up to custom query languages and even SQL.
Until the essence becomes clear, at least “post-relational” won’t put people who still like relational databases on their heels and better frames the discussions about what is changing.
Post-SQL would be more accurate. In my blog (previous comment) I put the case that the issues I’ve seen mentioned under the “NoSQL” banner are all problems with the SQL model rather than with the relational model per se. We shouldn’t rule out (non-SQL) relational alternatives.
I quite like “NoSQL”. Five letters, direct, and simple. But defining the movement as what it is instead of it isn’t does have some upside.
The strength behind these data stores is that they fit well with their domain. So
domain appropriate or domain driven data stores would be illustrative. We can even call them well-fitting, form-fitting, or dare I say, snug data stores.
I think Post-Relational is an accurate name for the _movement_ but not the various technologies that spawned it. There’s a big difference between a k/v store and a document database. But that’s not really important here. I think Adam is on the right track with encompassing the changing ideas about data storage. It’s a shift in thinking when the space has been dominated by relational thinking for so long.
Even 5 years ago when someone said “we should put it in a database”, 99% of the time, they were talking about an RDBMS. Now, instead of asking which one (MySQL, PostgreSQL, Oracle), you also have to ask what kind.
Intersystems has been calling their object database (Caché) “post-relational” for at least a decade.
I think Luigi is on the right track, and his names don’t assume a predecessor.
@Marco: asking “what kind?” is the crux of the biscuit. Right on.
@Jerod: how very avant-garde of them! ;)
“post-relational” is a bad choice IMHO, because people would imagine that NoSQL databases don’t support relations.
But this is the opposite. NoSQL databases have excellent support for relations, in fact, they are more relational than SQL databases. Objects (JSON-based or not) are interconnected using relations. Just in a way that is closer to the code than using artificial primary keys.
Oh and my suggestion would be SQL-Free databases.
Frank: I wouldn’t go so far as to say that, for instance, Tokyo Cabinet or even CouchDB are more relational than an RDBMS. They are _differently_ relational for sure. You can implement parts of the relational model in any database. Just look at many of the mapper/model libraries for MongoDB or CouchDB in Ruby to see examples of that. Whether it comes out feeling natural is a whole other bag of worms.
As a name, SQL-free has the same problem, IMO, as NoSQL: it’s confrontational and it’s not true. AFAIK, Pig implements SQL or something like it on top of Hadoop, but I would still consider it post-relational.
Being relational has nothing to do with objects being interconnected. It has to do with a data representation using Relations (http://mathworld.wolfram.com/Relation.html – a “table” being the nearest SQL gets to a relation) and data access using relational operators (relational algebra). In fact one of the key advantages of the relational model is that it eliminates any form of navigation between data items. It follows that navigational data models are definitely NOT relational by definition (actually neither is SQL, but for different reasons).
Post relational? I doubt that much will change in our code in the future. Databases will be multi node and memory-based instead of disk-based but they will still be relational and they will still use SQL (maybe via an ORM).
That means that devs don’t have to rewrite their data access layer and still can achieve big performance gains.
A distibuted key-value-store is great but a distributed memory based rdbms is even greater! Think of something like Groovy SQL Switch.
Column stores like vertica are also rdbms and sql based. rdbms is a logical model of data, not a physical model. Vertica, Greenplum, AsterData and Netezza are not postrelational but relational.
Document processing will be done with map reduce but that has never been done with sql so that isn’t a real change when it comes to the rdbms.