MongoDB: the document model for data that changes shape

OutsourcingVN is operated by Netbase JSC, and this page keeps that document-shape decision separate from the relational default most transactional records still fit best.

Implementation patterns

A MongoDB schema starts from the document, not the table: fields that are read and written together live in one document, and a design that groups unrelated data into the same collection usually costs more at query time than it saves at write time. Indexes on the fields a query actually filters or sorts by matter as much here as in a relational database; an unindexed query at scale is a common cause of slow MongoDB performance, and the fix is almost always naming the right index rather than changing the data model. MongoDB supports multi-document ACID transactions across collections, databases and shards, so a workflow that occasionally needs several documents to commit together does not have to leave the document model entirely, though the documentation notes that a distributed transaction carries a real performance cost and should not replace good schema design as the default way documents stay consistent with each other.

Backups and operation follow the deployment shape chosen: a self-managed replica set needs its own backup, failover and upgrade plan, while MongoDB Atlas, the vendor's managed service, runs on AWS, Google Cloud or Azure and takes on provisioning, patching, backup, monitoring and scaling through the same MongoDB query API applications already use, so moving to it does not change application code. On the multi-tenant cloud ERP record, MongoDB is one of four database engines in the stack, alongside PostgreSQL, MySQL and MariaDB, for a US client that is not named; phase one, from 2020 to 2023, covered CRM, real-time messaging, HR, a knowledge base, custom fields and workflows, work and project management and API integrations.

What trade-offs should you weigh?

1. Schema flexibility against enforced structure. A document model absorbs a changing shape without a migration for every new field, at the cost of the referential integrity a relational foreign key enforces automatically.
2. Document-level consistency against cross-document guarantees. A single document write is always atomic; a workflow spanning several documents can use a multi-document transaction, but the documentation is explicit that this costs more than a single-document write and is not a substitute for a schema that keeps related data together.
3. Self-managed control against a hosted service. Running MongoDB yourself keeps every configuration choice in house; MongoDB Atlas trades some of that control for provisioning, patching and scaling handled by the vendor, through the same query API either way.
4. Licence terms for a service you resell. MongoDB ships under the Server Side Public License, which requires the source of any service built on it to be published if that service is offered to third parties over a network; running MongoDB to serve your own product does not trigger that condition the way reselling database access would.

Where does AI fit on a MongoDB deployment?

With AI, every new capability — a retrieval index, an evaluation pipeline, a model-scoring step — is new to every supplier, and Netbase takes each one on and combines it into delivery rather than waiting for a long track record to form first. On a MongoDB-backed catalogue or content store, that usually means a ranking or recommendation feature reads from the same governed documents through an API rather than copying them into a private store, while MongoDB continues to serve the product's own reads and writes. A workload that needs a dedicated retrieval or relevance index across several products at once is better scoped through a shared platform than built again inside each application's own database.

What to check before committing

MongoDB supports multi-document ACID transactions on replica sets and sharded clusters, with the primary required to run the WiredTiger storage engine and documented restrictions on which operations a transaction can include, such as creating a collection inside a cross-shard write transaction. MongoDB Atlas, the vendor's own hosted service, manages provisioning, patching, backup, monitoring and scaling across AWS, Google Cloud and Azure, through the same query API as a self-managed deployment. Confirm before scoping a build:

• Whether the workload needs cross-document transactions at all, since the documentation is explicit that they cost more than single-document writes and should not replace a schema that keeps related data together.
• Which fields a query actually filters or sorts by, so the right index exists before the collection grows large enough for its absence to matter.
• Self-managed or Atlas, since the operational ownership differs even though the application-facing query API does not.
• Whether the service built on MongoDB will be offered to third parties over a network, since the Server Side Public License's disclosure condition turns on exactly that.

What Netbase has built with MongoDB

MongoDB is part of the stack of the multi-tenant cloud ERP, for a client and product that are not named; phase one, from 2020 to 2023, covered CRM, messaging, HR, a knowledge base, custom fields and workflows, work and project management and API integrations. The underlying stack adds PostgreSQL, MySQL and MariaDB alongside MongoDB, deployed on AWS. These are delivered as Custom Product Engineering milestones: most Netbase projects are agreed as fixed-scope contracts after discovery, following discovery and strategic alignment, team assembly and architecture planning, agile execution with outcome-based milestones, modular components, training and rollout, and ongoing support.

Where Netbase applies this stack

Sources

• MongoDB, Transactions
• MongoDB, MongoDB Atlas
• MongoDB, Server Side Public License