Schema-less or schema-LOSS

One of my applications utilized MongoDB. Right from the start, we gained a lot of benefits from the choice. Data got stored exactly the way it was needed by the application. It all fit into memory, and performance was amazing. The MongoDB replica sets in the recommended 3-node configuration provided redundancy, and assured high availability.  MongoDB would get good marks from me; it is a solid, mature product.

And it’s schema-less. The database just stores objects from the application. There is no overhead of defining and maintaining a schema definition. The application goes to production. Whenever a problem arises, code is changed and quickly deployed without dealing with the hassle of database administrators. And then, after three emergency fixes, comes a realization. What was an initial advantage is now a big problem. After each fix, data was created in a new format, and old data was retained “as is”. There is data in four different formats. There coexist four different schemas, without a clear way to tell them apart. It’s no longer “schema-less”, now it’s SCHEMA-LOSS.

Before NoSQL fixes were accompanied by database management tasks.  Database structures were altered and old data was migrated to the new schema. Now there is a functionality gap caused by the disappearance of a schema. Unless some other tool fills the gap, maintenance becomes a nightmare.