MongoDB CEO, Max Schireson recently said “Relational databases were designed in the 1970s during the time that computers were going from punch cards to terminals.” I admit there was a period of time where I bought into this thinking. Somehow, the thinking goes, if we just throw everything away and start from scratch we’ll do it 10x better. I suppose when you raise $231 million dollars you have to really sell it, then proclaim you are going to take down Oracle, then you have your team write posts on how to scale past 100GB.
These days I believe there is nothing a crotchety old relational database can’t handle for 99% of the use cases out there. I do admit though when designing a model dealing with a large number of columns with high cardinality being able to rely on a soft schema can really make things easy from a code perspective.
A design pattern I’ve been intrigued by lately is the hybrid approach. More specifically the introduction of the json datatype in Postgresql 9.2, and the improved set of functions in 9.3.
Previously a hybrid approach meant gluing your relational db with a NoSQL db or key value store at the application layer. You get flexibility, but the downside is you end up shifting all the logic into code and it becomes challenging to manage. With a PostgreSQL 9.2+ hybrid approach you can do your document storage in PostgreSQL while still taking advantage of things like constraints, foreign keys, & triggers. This allows you to tightly couple your structured and loosely structured data because your document store is effectively just another column. From both a data integrity and a developer productivity standpoint this is a huge win.
Here’s a good presentation by Andrew Godwin about rapid schema development with PostgreSQL with some high level tips & tricks. Christophe Pettus also created a good presentation on this approach which you can find here. Side note, I like the phrase “rapid schema” as it gets to the heart of what a schema free database promises which is the ability to change quickly. Unfortunately it’s sort of vague, like NoSQL.