A database is where your records are kept so a computer can find them. There isn't just one kind. Five big steps, each built to do what the one before couldn't, in a little over two minutes.
Your bank balance, your messages and your shopping basket are all records, kept somewhere a computer can find them. That somewhere is a database, and there isn’t just one kind.
This video is the brief history, up until now, told as five questions in the order they arrived. How do we count, which a punched card answered in 1890. Where is one record, which took the 1960s and databases you searched by following the branches. Ask anything, which is Edgar Codd’s tables of 1970 and the language SQL, still holding your bank balance today. A million users, which the web forced and NoSQL answered by loosening two rules. And the newest, meaning and connection, which vector and graph databases answer and an AI that seems to remember you is quietly using together.
The line to keep: when you hear the name of a database, ask what it was built to do, and the rest falls into place.
Every date and claim was checked against a primary source in September 2026: the US Census Bureau, IBM, the Computer History Museum, Codd’s paper, ISO, and the Bigtable and Spanner papers. This is an independent explainer, not affiliated with any vendor.
Transcript
Your bank balance, your messages and your shopping basket are all records, kept somewhere a computer can find them. That somewhere is called a database.
There isn't just one kind of database. Each new one was built to do something the last one couldn't. Let's look at the brief history, up until now.
The first question was how to count. In 1880 America counted its people by hand, and adding up the results took almost a decade. The answer was a punched card. Every person got a card, every answer became a hole in a fixed spot, and a machine could read the holes and count them in a fraction of the time.
Next came magnetic tape, which holds far more but plays from the beginning. Finding one record meant reading every record before it. In the 1960s, databases were built where each record sat under another, and you found one by following the branches. That was fast, as long as you asked a question the designer had already planned.
In 1970 Edgar Codd at IBM proposed keeping every fact in a table, with the tables referring to each other by number, and a language for asking them anything. That language is called SQL, and fifty years later it still holds your bank balance.
Then the web outgrew one machine. To spread records across thousands of computers, companies like Google loosened two rules. Records no longer had to share one shape, and a change didn't have to reach every machine before it counted. That family of databases is called NoSQL.
The newest questions are about meaning and connection. Find what I mean, not just the words I typed. That is the job of a vector database.
Find everything linked to this customer, however far the chain runs. That is the job of a graph database. An AI that seems to remember you is quietly using several of these together.
Every kind of database was built for one job the last one could not manage. First count, then find one record, then ask anything, then spread out, then find what I mean. When you hear the name of a database, ask what it was built to do, and the rest falls into place.
Found this useful?
Subscribe for the next one, or tell me what you want explained. I take requests.
