Database Management – Are Schema Migrations Problematic in Production?

databasenosqlrelational-databaseschema

In discussions about NoSQL vs SQL databases, I sometimes hear that companies prefer to use schemaless NoSQL databases because it is problematic to migrate the schema to a new version. But is that really a big problem when doing upgrades? Are relational databases bad for such operations?

I read this blog post on the MongoDB blog: Why Schemaless?

Best Answer

Just because your NoSql database doesn't have a schema in a traditional sense doesn't mean there isn't a logical schema you need to deal with as it changes. In the case of a typical app using MongoDb, most likely your code expects certain fields of the json object to behave in certain ways. If you change the behavior, it follows you might want to update the already existing data in the database. Now, with traditional RDBMS this was a largely solved problem -- you just had to ALTER the underlying tables. But with these newfangled NoSQL databases, you have a decision -- do you write a script to munge and update all your objects? Or do you add code to convert between versions on the fly? If so, how long do you support v1 objects? Forever? Until v3?

I'll add that the example used in the MongoDb blog post is a bit simplistic and a very easy case to handle if you've got a decent update process no matter what the RDBMS is; adding a field rarely hurts. It is when you decide to split your Name field into FirstName and LastName that things get exciting.

Related Topic