What is a database, and why is it its own specialty?

What is a database, and why is it its own specialty?

A database is organized storage that keeps a company's information safe and lets software find any part of it quickly. Every account, order, message, and payment a product remembers lives in one. The backend exists largely to guard it: when the frontend sends a request through the API, the backend's real work is usually reading from the database or writing to it.

It is a specialty because the stakes are lopsided. Most code can be rewritten next month with little drama. The database holds the data itself, and data is the one part of a product a company can never regenerate by typing. Lose the code and you rebuild. Lose the data and it is gone. That is why "database" is the second noun in almost every backend job description, right after the programming language.

What is a database?

A database is a program that runs on a server and does one job with total seriousness: store information, and answer questions about it fast.

The nearest familiar object is a spreadsheet, and the comparison is worth walking through because it shows what the extra engineering buys. A spreadsheet holds rows of information and one person edits it at a time. A database holds the same kind of rows at a vastly larger scale, answers thousands of requests per second, lets many programs read and write at once without corrupting anything, and guarantees that a saved change survives a power cut. A busy product might have a hundred thousand people using it in the same minute, every one of them triggering reads and writes. The database is the part of the system that makes that safe.

Every product that remembers anything has one. A store remembers inventory and orders. A social app remembers accounts and posts. Even a simple web app with a login page has a database behind it holding the accounts. When developers talk about "the data layer" or "persistence," this is the thing they mean.

What is a query?

A query is one request sent to a database. Fetch every order placed today. Find the account with this email address. Add this new message. Count the signups from last week. Each of those is a query, and the database's job is to answer it in a few milliseconds.

Software sends queries constantly. When a person opens their order history in an app, the frontend calls the API, the backend turns that call into a query, the database answers, and the result travels back up the same chain as the page the person sees. A single screen of an app might be built from five or ten queries. Multiply that by every user, and a mid-sized product's database answers millions of queries a day.

The word carries into job descriptions directly. "Query optimization" on a resume means making slow queries fast, which is detective work: finding the request that takes two seconds when it should take twenty milliseconds, and reshaping it. Developers who have done this at scale have usually felt a slow database drag a whole product, which is the experience the next section is about.

What is SQL?

SQL stands for Structured Query Language, and it is the language most queries are written in. Developers pronounce it both ways, "sequel" and "S-Q-L," and both are correct.

It is a programming language of a narrow, focused kind. Where a general language like Python can build anything, SQL does exactly one thing: describe what you want from a database. A SQL query reads closer to English than most code. SELECT name FROM customers WHERE city = 'Denver' means what it appears to mean.

Two facts make SQL unusual in a field where tools turn over every few years. First, it is old and stable: it dates from the 1970s and a query written decades ago still runs today. A developer's SQL knowledge from 2010 is current in 2026, which is true of almost nothing else on their resume. Second, it crosses role boundaries. Backend engineers write SQL to build features. Data engineers write it to move and shape data. Analysts write it to answer business questions. The same four letters appear in all three job descriptions, which makes it one of the most durable and most portable skills in the field.

Why is this its own skill?

Because the shape of the database sets a ceiling on the whole product, and that shape is expensive to change once real data is in it.

Early in a product's life, someone decides how the information will be organized: what gets its own table, how orders connect to customers, what gets stored where. Those decisions look small and they compound. A well-shaped database stays fast as the product grows from a thousand users to a million. A badly shaped one gets slower every month, and no amount of good code in front of it can fully compensate, because every feature ultimately waits on its queries.

Reshaping it later is the hard part. The database is live. Changing its structure means transforming millions of real records while customers keep using the product, with no acceptable version of "we lost some orders during the migration." Teams do pull this off, and the developers who have led one carry a skill that reads clearly on a resume. It is careful, high-stakes work, closer to renovating a building with the tenants still inside than to ordinary coding.

This is why database depth gets treated as a specialty rather than a chapter of backend work. Some engineers spend whole careers here, and larger companies staff dedicated data roles around it. The full journey those queries support, from a developer's keyboard to a customer's phone, is laid out in the station guide.

What kinds of databases are there?

Two families cover most of what appears in job descriptions.

A relational database stores information in tables with rows and columns, like a set of connected spreadsheets, and enforces the connections between them: every order must point at a real customer. This is the older family, it runs most of the world's serious products, and SQL is its native language. Postgres and MySQL are its two most widely used members. Both are free to use, both have decades of history, and they are close enough relatives that a developer strong in one works in the other after a short ramp. Postgres in particular has become the default choice for new products over the last decade, so it is the name you will see most on current resumes.

A document database stores information as flexible documents instead of fixed tables, so each record can have its own shape. MongoDB is the best-known member. The flexibility helps teams move fast early, when a product's shape is still changing weekly, and it trades away some of the guarantees relational tables enforce. Plenty of products use one of each, matched to different parts of the system.

For reading a resume, the useful rule is that the family matters more than the brand. The concepts inside a family transfer almost entirely, so Postgres, MySQL, and SQL experience form one connected body of skill, and a candidate listing any of them can pick up the siblings quickly.