The database is the layer a business's manager sees the least often, and yet it's the one that takes the most expensive revenge in the long run if it was designed poorly. A bad database structure doesn't show up in an error message right away — for weeks, months, it's "just" slow, and then one day it simply can't handle the load, or two reports show two different numbers for the same question. This article isn't about the technical details — it's about what's worth knowing so you can have a meaningful conversation about this with a developer.

Data should exist once, not twice

The most fundamental design rule is that every piece of information should have a single, authoritative home. If a customer's phone number is stored in both the order table and the customer table, sooner or later a discrepancy will appear between them — someone updates one, forgets the other, and from then on you don't know which one is true. This phenomenon, technically called data duplication, is one of the most common reasons a system becomes unreliable over time, even if it worked perfectly at the start.

The solution isn't complicated in theory: every data type has one "owner table," and everywhere else that needs the same data just references it — it doesn't copy it. In practice, this means that when a developer designs your system's data structure, they need to go through which pieces of information logically belong together, and which ones only appear elsewhere as a reference. This is the decision that's hardest to fix after the fact — the earlier you clarify it, the less pain waits for you two years down the line.

The growth you need to design for — before you need it

A database that works perfectly with a thousand records can completely collapse at half a million — not because it was written badly, but because the design didn't account for what happens when the volume grows tenfold. The most common symptom of this is a query that answered in one second at launch growing to ten seconds six months later — and with it, the entire user experience slows down, because the user waits on that slow query at every click.

The keyword for prevention is indexing: for data you search or filter often (customer name, order number, date), the system needs a fast lookup structure prepared in advance — much like a book's index, without which every search is equivalent to reading the whole book cover to cover. A good developer doesn't start dealing with this once the system is already slow — they assess during the design phase which data will be searched often, and build that in ahead of time.

What an SME manager really needs to know

You don't need to become a database expert to make good decisions. But there are three things worth clarifying with your developer at the start of every project. The first: what data volume are we planning for in two to three years — this is the one number the entire design logic depends on, and one the developer can't guess on your behalf. The second: who can access what — because the database structure and the permission system are tightly linked, and if you want to bolt this on afterward, it often means rethinking the entire structure.

Good database design isn't more expensive than bad design at the start of the project — the difference only shows once the system is live, and every change comes with real data and real risk.

The third thing to ask about: what happens with invalid or missing data — does the system allow an order with no customer attached, or an invoice with no line items? These rules, technically called "constraints," are what prevent bad data from entering the system in the first place — without them, errors only surface once they're already expensive to fix.

If an existing system of yours is starting to slow down, or you want a solid foundation when planning a new project, let's talk about it — we'll go through what to prepare for.