How Databases Protect Accuracy

The principles of entering, searching, updating, and transacting

Part 2 of 12 in "Databases for Non-Developers." Part 1 described the database as "the memory of an organization." This time we look at the mechanisms that keep that memory from becoming distorted — input rules, transactions, indexes, replication, and backup.

---

Imagine two people booking the last seat of a concert at almost exactly the same moment. Both of their screens show "1 seat left." But there is only one seat to sell. The database must give the seat to one of them and tell the other it's sold out.

This seemingly simple situation reveals something important about databases. A database does more than store information — it must process simultaneous changes in an orderly way.

What Happens When Accuracy Breaks Down

Before we look at the mechanics, let's be clear about why they matter. Part 1 asked "why do we need to manage data well?" — this time the question is "what exactly does it cost when accuracy breaks?"

• Double-selling and overbooking: If there is one item or seat but it gets sold to two people, one of them ends up with a refund, an apology, and a lost willingness to come back.
• Balance errors: If a bank balance shows a different number on every screen, customers will withdraw their money and leave immediately. In finance, accuracy is a matter of survival.
• Prescription errors: If a drug dosage is recorded incorrectly in a hospital system, it stops being a technical problem and becomes a safety problem.
• Silent contamination: There is a scarier case, too — data drifting slightly wrong while nobody notices. When months of reports and decisions pile up on top of bad data, tracing "since when has this been wrong?" costs far more than fixing the error itself, even once it's discovered.

The database's accuracy mechanisms exist to prevent these accidents. Let's look at them one by one.

Input Rules: Not Just Any Value Gets In

If an email address ends up in a date-of-birth field, or an order gets attached to a customer number that doesn't exist, trouble follows. A database can enforce rules like these:

• Order numbers never overlap
• Quantities must be greater than zero
• An order must be linked to a customer who actually exists
• Payment dates must be recorded in a set date format
• Fields that are truly required cannot be left blank

These rules are called data constraints. In plain terms, they are a checkpoint at the door that screens out bad values before they get in.

There is one important principle here. The earlier an error is caught, the cheaper it is. An error filtered out at the input stage costs a penny; an error that flows through the database and contaminates reports and management decisions can cost a fortune to undo. That's why blocking problems at the entrance is cheaper than cleaning them up later (Part 6, "Data Quality" covers this in depth).

Transactions: All of It Happens, or None of It Does

When you transfer money from bank account A to account B, at least two changes are needed. Subtract the money from A's balance, and add it to B's balance. If only the first step succeeds and the second fails, the money vanishes into thin air.

A database can bundle related operations into a single transaction. If every operation succeeds, the transaction is committed; if something goes wrong midway, everything is rolled back to the original state. It's like ordering a set menu at a restaurant and never being charged for only part of it.

Developers describe the properties a transaction must guarantee with the acronym ACID. Non-developers only need to remember one question:

Is it okay for just one of these steps to succeed, or must they all succeed or all be canceled together?

This matters most for operations where numbers and rights change hands — payments, bookings, point transfers, inventory deductions. When reviewing a product spec, simply asking "what happens if this fails midway?" is often enough to expose design flaws early.

Indexes: Like the Index at the Back of a Book

Searching through millions of customer records from the beginning just to find one email address would take far too long. An index works like the index at the back of a book, letting you jump straight to the record you want.

But more indexes are not automatically better. Just as a book with more index entries takes more effort to edit, every change to the data means the indexes must be updated too. You should look at which searches actually happen often and create only as many indexes as you need. If you notice "searches are fast, but saving new data has slowed down," it's worth taking a hard look at the index design.

Replication and Backup Are Not the Same Thing

Two concepts people often confuse:

• Replication copies the same data to another server, almost in real time, so the service can keep running if one server goes down.
• Backup keeps a separate copy of the data as of a specific point in time, so you can restore a past state after a mistake, corruption, or attack.

Here is a scenario that shows the difference. An employee accidentally deletes a customer record, and that deletion is instantly reflected in the replica, too. The replica is now deleted in exactly the same way. Replication alone cannot save you. On the flip side, even if you have a backup, if restoring it takes hours, the service is down for those hours.

In other words, replication protects "service continuity," while backup protects "the ability to go back in time" — they are different mechanisms solving different problems, and you need both. And right after "do we have backups?" must always come "have we tested a restore?" A backup that has never been restored is just a possibility, not a guarantee.

The Choice Between Fast and Accurate

Not every service demands the same level of instant accuracy. A bank balance can't show different numbers on different screens. But the like count on a post being slightly out of sync across screens for a few seconds is probably acceptable.

Storing data across multiple regions can improve speed and fault tolerance, but keeping every copy in perfect sync at every moment becomes much harder. So database design doesn't ask "what's the fastest?" first — it asks "how much discrepancy and delay can this operation tolerate?"

This is not a question only the engineering team can answer. "Can the stock count lag by 10 seconds?" and "Does the booking confirmation screen have to be instantly accurate?" are business questions. This is why business stakeholders need to be part of this conversation.

Key takeaways A database's value lies less in how much it can store than in how accurately it handles change. Input rules keep bad values out, transactions make a group of operations succeed or fail together, indexes speed up searches but cost effort to maintain, and replication (service continuity) and backup (going back in time) solve different problems. And "how accurate does it need to be?" is a business decision, not a technical one.

Questions to Think About

• Which operations in our service must never succeed only halfway? (Payments, bookings, points...)
• Have we separated the areas where data can lag a few seconds from those where it must be instantly consistent?
• When did we last test an actual restore from backup?
• If our data were being silently contaminated, how many days would it take us to notice?

Next: We look at the different types of databases and how they vary by data shape and purpose. From relational to vector databases — why are there so many kinds?

---

Series contents

1. What Is a Database — How Is It Different from an Excel File?
2. How Databases Protect Accuracy ← You are here
3. What Kinds of Databases Are There?
4. Databases, Data Warehouses, and Data Lakes
5. Why Choosing the Right Database Matters
6. Data Models and Data Quality
7. What Is Data Governance?
8. Less Personal Data, Only What's Needed
9. The Basics of Data Security
10. Why Do Data Breaches Happen, and What Should You Do When One Does?
11. Cloud and Serverless Databases
12. Databases in the AI Era