What a database is, what it's doing under the hood, and why there are so many of them with different names. Written for people who live in spreadsheets and have started bumping into their limits.
If you know Excel, you already understand most of a database. A table is a worksheet. A column is a column. A row is a row. That's not a simplification to be polite — it's genuinely the same shape.
The difference is what surrounds it. A spreadsheet is a file you open. A database is a program that runs, guards the data, and answers questions about it. You never open the file; you ask the program.
Four ideas cover almost everything:
amount column holds numbers —
the database will simply refuse to store "N/A" in it. That refusal is a feature: it's how
bad data gets stopped at the door instead of found at year end.customerNumber). No duplicates, ever.customerNumber, so it belongs to a customer. This is the
wiring that lets you ask questions across tables.Those keys are why you don't repeat the customer's name and address on all 47 of their orders. You store the customer once and point at them. Change the address in one place and every order reflects it — no find-and-replace, no drift.
VLOOKUP. It can't go stale, can't point at a deleted row, and doesn't break when
someone inserts a column.Want to see real ones? The schema explorer draws the keys and relationships of every sample database on this site.
A database is a server: a program sat waiting for requests. Your tool — DBeaver, Excel, this website — is a client. Here's the whole round trip:
You send SQL. The client opens a connection (a host, a port, a username) and sends your statement as plain text.
The database parses and plans it. It checks the SQL makes sense, then a component called the query planner works out how to get your answer — which is often not the order you wrote it in.
It uses indexes to avoid reading everything. An index is a sorted lookup structure — like the index at the back of a book. Without one, finding a customer means reading every row. With one, it's a handful of jumps. This is the single biggest reason databases stay fast at a million rows.
It reads the rows and builds a result set. Filtering, joining and totalling all happen inside the database, on the server — not on your laptop.
It sends back only the answer. Ask for one number and you get one number, even if it summed a million rows to get there.
You can watch this happen: every response from our
REST API includes the exact sql it ran, and the
SQL Editor shows results the moment the server replies.
Use Excel. It's excellent. But the moment more than one person needs the same numbers, the cracks show:
That last one deserves a name. A transaction means a group of changes succeeds or fails as one unit. Moving $500 between accounts is two steps — debit one, credit the other — and a database guarantees you can never end up having done only the first, even if the power dies in between. Accountants have a word for systems without that guarantee: out of balance.
You'll hear a lot of names. Almost all of them fall into two camps:
Data in tables, with keys wiring them together, queried with SQL. Every example on this site is relational. If your data has a natural shape — customers have orders, orders have lines — this is the right tool, and it's the overwhelming default in finance and accounting.
A family of databases that deliberately drop the table structure for something looser — documents (MongoDB), key-value pairs (Redis), graphs (Neo4j). They're built for problems like caching, huge unstructured logs, or social networks. They are not a newer, better version of relational databases, and you almost certainly don't need one to analyse financial data.
These are all relational databases that speak SQL. They differ in who makes them, what they cost, and where you'll run into them — far more than in how you query them.
The enterprise standard in corporate finance. If your company runs Dynamics, or your accounting system has a Microsoft back end, this is very likely what's under it.
SELECT TOP 10The most widely deployed open-source database, and the friendlier one to learn on. MariaDB is a compatible fork of MySQL — for learning purposes they're the same thing.
LIMIT 10Free, open source, and the darling of data teams — very standards-compliant and strong at complex analytical work. A great third one to know.
A whole database in a single file, with no server at all. It's on your phone right now. Perfect for small, local, single-user data.
SELECT, FROM,
WHERE, JOIN and GROUP BY are identical in all four.
Learn SQL once and you can work with any of them; the differences are dialect trivia you look
up when you need it. We've tabulated the exact
SQL Server vs MySQL differences here →Neither — learn SQL. The language is the transferable skill; the engine is a detail of whichever job you're in. That said, if you want a practical answer:
Both engines on this site carry the same sample databases, so you can run an identical query against each and watch what changes. That's the fastest way to stop worrying about it.