Bespoke software development services
in Somerville

Every custom build eventually needs an answer to a question that has nothing to do with the interface: where the data actually lives, and in what shape. A relational database stores information in fixed tables with defined columns and enforces relationships between them. A document database stores each record as a flexible block, closer to the shape the application already uses in memory. The shapes differ. No shared table structure forces every record to look the same.

The relational choice earns its reputation when the data has clear, stable relationships that the business genuinely depends on. An order belongs to a customer. It contains several line items, and each line item points to a product. A relational schema enforces that structure at the database level, so an order can never reference a product that does not exist. A document store rarely enforces that cleanly. Nothing stops two related records from drifting out of sync unless the application code checks constantly.

A document database earns its place when the shape of the data varies from one record to the next, or changes often as the product evolves. The fit is obvious here. A catalog of items from different suppliers, each with its own set of attributes, or a log of events with a different payload for each event type, tends to fit a document model far better than a rigid table. Adding a new field to some records should not require altering every row that already exists.

Query patterns matter as much as the shape of the data. A relational database handles a question that spans several types of record, such as total spend by customer across every order and every line item, through a single query built for exactly that purpose. A document database answers that same question far more awkwardly. It stores each order as one block. The cross-cutting answer then means pulling many records into the application and combining them there, instead of letting the database do the work.

Consistency rules split the two approaches further, and this is the part a team notices only after launch. A relational database, correctly configured, will not let two operations overdraw the same balance to zero at once. It locks the row and makes the second operation wait. Many document databases favor availability over that kind of strict locking. The trade-off is real. It suits a shopping cart or a page of comments well enough, and it is risky for anything involving money, inventory counts, or a limit that must never be exceeded.

Mixing both inside a single build is common and reasonable, not a compromise forced by indecision. A system can keep orders, payments and account balances in a relational store where consistency matters, while storing product descriptions, activity feeds or search results in a document store built for flexible, high-volume reads. Both can coexist. The two live side by side, each handling the part of the job the other does poorly, connected by the application rather than by any single schema.

The decision is also expensive to reverse once real data has accumulated, which is the strongest argument for spending real time on it early. Migrating years of transactional history from one storage model to another, while the business keeps operating on top of it, is a project of its own, often larger than the original build. Few teams plan for that cost. A short exercise mapping the actual entities, their relationships and the questions the business will ask of them, done before the first table or collection is created, tends to save far more time than it costs.