What is a database? How apps store and find data

A database is an organized collection of data, stored so that it can be searched, updated and kept correct, together with the software that manages it, called a database management system. Nearly every app keeps its accounts, messages, orders and settings in one. The software's job is to find any piece of data fast, let many users change it at once without clashing, and never lose what it has been told to keep.

In short

• A database is data plus the system that stores, searches and protects it; the most common kind keeps data in tables of rows and columns.
• People and programs ask it questions in a query language, usually SQL, saying what they want rather than how to find it.
• Indexes make lookups fast, and transactions make sure a change happens completely or not at all.

What does a database do that a file can't?

A list of customers could live in a text file or a spreadsheet. That works until three things happen: the list grows to millions of rows, many people need to change it at the same moment, and a mistake or a power cut in the middle of a change must not leave it half done. A database management system is built for exactly those problems.

It keeps the data in a structure designed for fast searching, so finding one customer among 10 million doesn't mean reading all 10 million. It controls simultaneous changes, so two people booking the last seat on a flight can't both get it. It enforces rules, such as "every order must belong to a real customer". And it writes changes so they survive a crash. Underneath, it is a carefully chosen set of data structures on disk and in memory, with algorithms for using them.

What is a relational database?

The most widely used kind stores data in tables, which the computer scientist Edgar F. Codd, working at IBM, described in his 1970 paper A Relational Model of Data for Large Shared Data Banks. Each table holds one kind of thing. Each row is one item, and each column one fact about it. Tables connect through shared values instead of copies.

Here is a tiny shop's database, two tables of it.

customers

id	name	city
1	Ana	Lisbon
2	Ben	Leeds
3	Chloe	Lisbon

orders

id	customer_id	total	placed
101	1	42.00	2026-10-02
102	2	15.50	2026-10-03
103	1	8.25	2026-10-07
104	3	60.00	2026-10-09

Notice that an order doesn't repeat Ana's name and city. It holds only her id, 1, a link called a foreign key. If Ana moves to Porto, the database changes one row, and every order is automatically up to date. Storing each fact once, and linking to it, is the central idea of the relational model.

How do you ask a database a question?

With a query, usually in SQL, the Structured Query Language that grew out of IBM's work on Codd's model in the 1970s and became a standard in the 1980s. Suppose the shop wants to know how much each customer in Lisbon has spent.

SELECT customers.name, SUM(orders.total) AS spent
FROM customers
JOIN orders ON orders.customer_id = customers.id
WHERE customers.city = 'Lisbon'
GROUP BY customers.name
ORDER BY spent DESC;

Read it aloud: "From the customers, joined to their orders wherever an order's customer number matches a customer's id, keep only customers in Lisbon. Group the rows by customer name, add up each group's order totals and call that spent. Show the name and the amount, biggest first."

Step by step, the database pairs each order with its customer (101 with Ana, 102 with Ben, 103 with Ana, 104 with Chloe), drops Ben's because he is in Leeds, adds Ana's two orders to 50.25 and leaves Chloe's at 60.00, and sorts. Run in SQLite, the answer is Chloe, 60.00, then Ana, 50.25.

The query never says how to find anything: which table to read first, or whether to search or scan. SQL is declarative, a different style from most programming languages, and the database's query planner works out the fastest way to answer.

What is an index, and why does it make lookups fast?

An index is a separate, sorted structure that points to where rows are, like the index at the back of a book. The PostgreSQL documentation uses exactly that picture: without an index, the system "would have to scan the entire" table, "row by row"; with one, "it might only have to walk a few levels deep into a search tree", the way a reader looks up a term at the back instead of reading the whole book.

You can watch the difference. Asked for every order from customer 1, SQLite's planner reports "SCAN orders": it will read every row. After one line, CREATE INDEX orders_by_customer ON orders(customer_id), the same question gives "SEARCH orders USING INDEX orders_by_customer": it goes straight to the matching rows. With four orders that saves nothing. With 10 million, a scan reads 10 million rows, while a tree index, typically only three or four levels deep at that size, reads a handful. Some databases also offer indexes built on a hash function, which are even faster for exact matches but can't answer range questions such as "orders placed in October".

Indexes aren't free. Each one takes storage and must be updated on every insert and change, so the documentation advises removing indexes that are seldom used. Choosing them is a bet on which questions people will ask most.

How are relational and NoSQL databases different?

Since the 2000s, many systems have been built that don't use tables and SQL, grouped under the name NoSQL, usually read as "not only SQL". They trade some of the relational model's guarantees for flexibility or for spreading data across many machines.

Kind	How it stores data	Good at	Examples
Relational	Tables of rows and columns, linked by keys	Data with clear structure and rules: money, orders, bookings	PostgreSQL, MySQL, SQLite
Document	Self-contained records, often in JSON	Records whose fields vary from one to the next	MongoDB, Firestore
Key-value	One value per key, like a giant dictionary	Very fast lookups, caches, sessions	Redis, DynamoDB
Graph	Items and the links between them	Questions about connections: friends of friends, routes	Neo4j

The line has blurred. Relational databases now store JSON documents, and several NoSQL systems have added SQL-like query languages. The usual advice is to start from what the data looks like and which questions it must answer, not from the label.

Where are databases in everyday life?

Everywhere software remembers something. The SQLite project estimates that its small embedded database runs on every Android phone and iPhone, and that over a trillion SQLite databases are likely in active use. Large services run their databases on rented machines, part of cloud computing, and apps reach them through an API rather than directly.

The guarantee that matters most is the transaction. Moving $100 from one account to another means subtracting from one and adding to the other. A transaction groups the two so the database does both or neither, even if the power fails between them. That property, with three related ones, is known as ACID: atomicity, consistency, isolation and durability. It is the main reason banks, airlines and shops keep their records in a database rather than in files.

Check yourself

• Without looking back, explain why the orders table stores a customer id instead of the customer's name and city.
• Read the example SQL query aloud in plain words, and say what it returns.
• What does an index cost, and when is that cost worth paying?

Sources

• A Relational Model of Data for Large Shared Data Banks — Edgar F. Codd, Communications of the ACM, 1970
• Indexes, introduction — PostgreSQL Global Development Group
• Query planning — SQLite
• Most widely deployed and used database engine — SQLite
• Database — Wikipedia