Databases for Backend Engineers: SQL, NoSQL, and Indexes

An API is only useful if there's data behind it, and that data lives in a database. Most backends are, when you squint, a thin layer that turns API requests into database queries and back. So a working grasp of databases — what kinds exist, why indexes matter, and what transactions guarantee — is core backend knowledge, not an advanced topic.

What a database actually gives you

Two things a plain file can't reliably do:

1. Durability — your data survives crashes and restarts; it's safely persisted.
2. Efficient querying — you can ask precise questions ("all orders over $100 from last week") and get answers fast, even over millions of rows.

Everything else is detail on top of those two promises. The big first fork is how a database structures data: relational or NoSQL.

Relational databases (SQL)

Relational databases store data in tables — rows and columns with a defined structure — and let tables relate to each other (a user has many orders). You query them with SQL, a declarative language where you describe what you want and the database figures out how to get it:

SELECT name, total
FROM orders
WHERE total > 100;

Their strengths are structure and integrity: the schema enforces what data is valid, and relationships keep it consistent. For the vast majority of applications — anything with clearly related, structured data — a relational database is the sensible default.

NoSQL databases

NoSQL is an umbrella for databases that relax the strict table model, each trading something for a specific benefit:

Indexes: the most important lever

Whatever database you pick, one concept dominates performance: the index. Without one, finding matching rows means scanning every row — fine for hundreds, catastrophic for millions. An index is a separate lookup structure (think the index at the back of a book) that lets the database jump straight to matching rows.

The catch is that indexes aren't free: each one takes storage and must be updated on every write, so you index the columns you search and sort by, not everything. The single most common cause of a "the database is slow" incident is a missing index on a frequently-queried column — which is why this idea earns its place in chapter one of databases.

Transactions: all or nothing

Some operations must happen together or not at all. The classic example: moving money debits one account and credits another. If the debit succeeds and the credit fails, money vanishes. A transaction bundles multiple operations so they all commit or all roll back.

Relational databases provide strong transactional guarantees (often summarized as ACID), which is a big reason they dominate anywhere correctness matters — finance, orders, inventory. Many NoSQL systems offer weaker or narrower guarantees in exchange for scale, so if your data has invariants that must never break, check what its transactions actually promise.

Choosing a database

A pragmatic decision procedure:

• Start relational. For structured, related data with correctness needs, it's the safe, capable default.
• Reach for NoSQL with a specific driver — an access pattern (simple key lookups), a scale requirement (enormous write volume), or a data shape (deeply connected, or wildly variable) that relational handles awkwardly.
• Match access patterns, not trends. How you'll read and write the data should drive the choice more than the label on the box.

Recap

• A database gives you durability and efficient querying — most backends are a layer over one.
• Relational (SQL) databases use structured tables and relationships with strong integrity — a strong default.
• NoSQL relaxes that model (document, key-value, and more) for flexibility or scale — choose it for a reason.
• Indexes are the biggest performance lever: they let the database skip full scans, at the cost of storage and write speed.
• Transactions make grouped changes all-or-nothing — essential wherever partial updates would corrupt data.

Our backend can store and serve data. But endpoints that touch real data must know who's calling. That's authentication. Continue to Authentication Basics.