Document databases, edge storage and vector indexes all have their place. For most business applications, a traditional relational database is still the right choice. Here is the reasoning we use.
The choice of technology is one of the few decisions in a project that is genuinely hard to reverse. So we favour tools with long support lifetimes, large pools of skilled people and predictable behaviour when things go wrong. For storing data, that usually means a relational database.
The questions we ask before choosing
- Do relationships in the data matter for correctness? If every invoice must belong to a real customer, a foreign key is the cheapest guarantee available.
- Will the structure of the data change more often than the questions asked of it, or the other way round?
- Can the client’s team, or whoever takes over the system, run it reliably at two in the morning?
- If we are wrong, what does the path to a different database look like in three years?
When we choose something else
Data whose structure genuinely varies, very high volumes of incoming events, full-text search at scale and similarity search are all cases where a specialised database earns its place. We add it alongside the relational database rather than replacing it, and we record why.
The failure we are trying to avoid
The most expensive systems we have taken over were not badly written. They were built on technology chosen because it was new, by people who had since left, and nobody locally could support them. An exciting technology becomes a liability if it makes the system impossible to maintain.