MongoDB often looks simple during the first few application releases. Developers can add fields without waiting for a table change, nested-objects map naturally to application code, and a complete business record can be retrieved without several joins.
The real test starts after the collection grows, multiple services begin writing to it, and the workload becomes operationally important. One service stores an identifier as a string while another writes it as a number. Arrays grow without limits. Queries that were fast during development begin examining millions of documents. A secondary falls behind during a batch update, or a shard key concentrates most traffic on one node.
The real test starts after the collection grows, multiple services begin writing to it, and the workload becomes operationally important. One service stores an identifier as a string while another writes it as a number. Arrays grow without limits. Queries that were fast during development begin examining millions of documents. A secondary falls behind during a batch update, or a shard key concentrates most traffic on one node.
MongoDB is not difficult because it uses documents instead of tables. It becomes difficult when flexible modelling is treated as a replacement for data governance, indexing, recovery planning, and capacity management. This article looks at MongoDB from a production DBA perspective and focuses on the design and operational decisions that usually determine whether the platform remains stable.