I just finished reading Rob Conery's current post, titled "JSONB and PostgreSQL: Work Faster By Ditching Migrations" and it sparked some good and bad reactions in me. I hope I can address some of the points made in Rob's post and to share my experiences. My intention is not to scream WRONG, but to start an intelligent dialogue. As a developer, I have built some excellent systems on top of JSON based databases, maintain some less than good JSON implementations, and currently developing some new SQL-based systems using migrations.
What Is A Migration?
In my opinion, the post starts with a concept of migrations that is a little skewed by Rob's opinion of ORMS, I'm assuming ActiveRecord from the initial reference to Ruby On Rails.
Migrations are a simple mechanism whereby you script out some change commands for your ORM, and that ORM then builds your database for you.
- Rob Conery
Here is what I feel is a more appropriate definition.
Migrations are a simple mechanism whereby you define change commands for a database.
Some ORMs come with migration frameworks, but I wouldn't tie the two together so tightly. There are plenty of migration libraries that lean on raw SQL. Even those libraries that have a code DSL do not impose a DSL-only approach. Some of these frameworks include:
*Note: I hate EF's migration strategy of binary hashes, but that's another post.
JSON databases aren't immune from needing migrations. I wrote a migration library that has been downloaded over 2,000+ times.
Is That Friction In Your Database, Or Are You Just Happy To See Me?
The first part of the post proposes that database migrations are a burden, and impose unnecessary friction. I would answer with "it depends on a lot of factors." The burden hinges on some of the following:
- The complexity of the schema (or lack of schema)
- The size of the development team
- The timeline of the project
None of these factors mean I have to use migrations, but I've found as these factors get larger and longer, the more likely I'll want to have migrations in my project. Migrations allow me to communicate many changes to a larger team, distribute those changes effectively, and apply them consistently. The friction of adding a migration is much less than the friction of dealing with all the factors described previously.
JSON Is Awesome, but...
Here is what I believe the point of Rob's post is: JSON is fast and fun to design and develop with, and developers should try PostgreSQL and its JSONB support.
Let it go. Use JSONB to freely design your storage and when the time is right, normalize that shit. Or don't - it's up to you.
- Rob Conery
I really can't argue with this. I love prototyping and developing on top of JSON databases. The relational impedance mismatch is all but gone, and the feeling of speed can be intoxicating. The problem is, the development experience is fun, but I've found that the production experience can be painful, and so have others.
Remember, the application will live most of its life in production. At this point, the SQL tools ecosystem is much more robust than any JSON tool ecosystem. It is acceptable when developers are absorbing the pain of managing a document database; it is another issue entirely when that pain begins to affect the stakeholders. This comic sums up my experience with business users.
Also, I can't talk about developing with document databases without making a Seinfeld reference.
PostgreSQL/JSONB is probably awesome; I am even excited about some new libraries like Marten. That said, document databases have their pros and cons, just like relational databases do. From my personal experience, the euphoria from using document databases happens during development. The high quickly fades when in production. Evolution becomes more necessary as soon as the application is in production, and migrations add a predictable and consistent approach to evolving a system in use. Evolution is not the exclusive domain of relational databases; it affects JSON based applications too. I am currently writing several medium sized systems and letting them evolve with the help of database migrations.
I'm having fun and thought I would share :).