What Are Relational Databases and Are They Still Relevant?

A relational database is a system for storing data as a set of tables — rows and columns, like structured spreadsheets — where the relationships between different tables are defined explicitly through shared key values, and a standardized query language (SQL) is used to read, write, and combine that data. The “relational” in the name refers specifically to this idea: rather than storing everything about a customer’s orders inside one giant record, you store customers in one table and orders in another, and link them together through a key they share — which is what lets the data stay organized, non-redundant, and queryable in flexible ways rather than locked into one fixed shape.

Tables, Rows, and the Keys That Connect Them

Every relational database is built from the same basic unit: a table. A table represents one type of thing — customers, orders, products — with each row representing a single instance of that thing, and each column representing one attribute of it. A customers table might have columns for name, email, and signup date; an orders table might have columns for order date, total amount, and which customer placed it.

The relational part comes from how these tables connect. Each row in a table is typically given a primary key — a value that uniquely identifies that row within its table, and never changes. Other tables reference that row not by copying its data, but by storing its primary key as what’s called a foreign key. An order doesn’t need to repeat a customer’s name and email — it just stores the customer’s ID, and the database can look up everything else about that customer whenever it needs to. This is the entire mechanical basis of “relational”: data lives in exactly one place, and everything else refers to it rather than duplicating it.

Why Data Gets Split Up This Way: Normalization

The discipline behind deciding how to split data across tables like this is called normalization. Its underlying goal is straightforward: eliminate redundant, duplicated data so that any single fact is stored in exactly one place. If a customer’s email address were copied into every order they ever placed, updating that email would mean updating it in dozens or hundreds of rows — and if even one got missed, the database would now contain contradictory information about the same customer. By storing the email once, in the customer’s own row, and having every order simply reference that customer’s ID, an update happens in one place and is instantly reflected everywhere it matters.

This is also what gives relational databases their reliability under real-world usage: normalized structure directly prevents the kind of silent data drift that happens when the same fact exists in multiple places and those copies quietly fall out of sync with each other over time.

SQL: The Language That Makes This Usable

None of this structure would be useful without a way to actually query it, and that’s the role SQL (Structured Query Language) plays. SQL is the standard language relational databases use to retrieve data, filter it, combine rows across multiple tables through their key relationships, and modify records — and it’s shared, with only minor variation, across the vast majority of relational database systems, which is a large part of why relational databases became as dominant as they did: the skills and the queries you write largely transfer from one system to another.

A single SQL query can pull a customer’s name from one table and their most recent order total from another, joining the two through the foreign key relationship, without you having to manually cross-reference anything yourself. This ability to combine data across tables on demand, rather than needing it pre-combined and duplicated ahead of time, is one of the most practically useful properties of the relational model.

The Guarantees Underneath: ACID

Beyond structure and query language, relational databases are defined by a set of reliability guarantees known by the acronym ACID: Atomicity, Consistency, Isolation, and Durability. Atomicity means a multi-step operation either completes entirely or doesn’t happen at all — if you’re transferring money between two accounts and the process fails halfway through, the database won’t leave you in a state where money vanished from one account without appearing in the other. Consistency means every transaction moves the database from one valid state to another, never leaving it in a state that violates its own rules. Isolation means concurrent transactions don’t interfere with each other’s intermediate, half-finished states. Durability means that once a transaction is confirmed as complete, it survives a crash or power failure — it’s actually been written somewhere permanent, not just held in memory.

These guarantees are why relational databases have historically been the default choice for anything involving money, inventory, or any other data where “approximately correct” isn’t good enough — a banking system, a booking platform, an e-commerce checkout. The cost of that reliability is real: enforcing these guarantees, especially in a system spread across multiple machines, takes coordination work that a system with looser guarantees doesn’t have to do.

Why They Became the Default

The relational model dates back to a 1970 paper describing how data could be organized as mathematical relations — tables — rather than the more rigid, pointer-based hierarchical and network database designs that came before it. That earlier generation of databases tied your ability to query data directly to how it was physically structured on disk, meaning any new kind of question you wanted to ask often required restructuring the database itself. The relational model decoupled logical structure from physical storage: you could ask new, unanticipated questions of the data using SQL without redesigning anything, simply by writing a new query.

That flexibility, combined with the strong consistency guarantees of ACID, is what let relational databases become the standard foundation for business software for decades — a track record long enough that a huge share of enterprise software, and by some measures a majority of production applications and databases still running today, are built on relational systems.

Where the Model Starts to Strain

The same properties that make relational databases so reliable also make them harder to scale in certain directions. Scaling a relational database vertically — giving a single machine more CPU, memory, and faster storage — works well up to a point, but eventually runs into the physical limits of what one machine can do. Scaling horizontally — spreading the database across many machines instead — is considerably harder for a relational database than it is for many newer alternatives, precisely because ACID guarantees require coordination between machines to stay true: if a transaction touches data that’s now split across multiple servers, keeping isolation and consistency intact means those servers have to communicate and agree before the transaction can complete, which adds latency and complexity that a single-machine system never had to deal with.

This is solvable — sharding a relational database, splitting its data across multiple machines by some partitioning key, is a well-established technique — but it’s genuinely harder to get right than scaling a system that was designed with distribution as a first-class assumption from the start. This is the real, technical basis behind the recurring question of whether relational databases can keep up at very large scale: not that they can’t scale at all, but that doing so requires deliberate, non-trivial engineering effort that isn’t automatic the way it can be in systems built differently from the ground up.

How the Alternatives Actually Differ

This is also the context that explains why non-relational (NoSQL) databases exist at all — they’re not simply “newer” or “better,” they represent a different set of trade-offs. Many NoSQL databases relax some of the ACID guarantees, or store data in more flexible, often denormalized structures, specifically to make horizontal scaling and high write throughput easier to achieve. A document database, for instance, might store all of an order’s related data — including a copy of relevant customer details — inside a single record, trading the “one source of truth” property of normalization for the ability to fetch everything about an order in a single lookup, with no join required.

Graph databases represent yet another distinct trade-off, optimized specifically for data that’s naturally shaped like a dense web of interconnected relationships — social networks, recommendation systems, fraud-detection networks — where traversing many-layered relationships between records is the dominant kind of query, something relational joins can technically express but that graph structures represent more directly and query more efficiently as the number of relationship “hops” grows large. None of this makes relational databases obsolete against these alternatives — it means each model is suited to different shapes of data and different access patterns, and the right choice depends on which properties you actually need.

How Relational Databases Compare to Vector Databases

A more recent comparison worth making explicitly is between relational databases and vector databases, because the two are built to answer fundamentally different kinds of questions rather than competing for the same job. A relational database answers exact, structured questions — find the order with this ID, find every customer whose signup date falls in this range — using precise matching against indexed columns. A vector database answers approximate, similarity-based questions — find the items most semantically similar to this piece of text or image — by storing data as high-dimensional numeric vectors and searching for the nearest neighbors to a query vector, rather than looking for an exact match at all. Asking “which is better” doesn’t quite make sense once you see this: a relational database has no native way to express “find me things like this,” and a vector database has no native way to enforce that an order’s total matches the sum of its line items with transactional guarantees. They solve different problems.

This is exactly why “relational database with vector search” and “hybrid search” have become common things to look for. Rather than treating this as an either-or decision, a growing number of systems combine both capabilities: some established relational databases now ship extensions that add vector storage and similarity search directly alongside their existing structured tables, letting a single system run an exact filter — a stock check, a permissions check, a date range — pre-filtered before the similarity search even runs, and a semantic similarity search over embeddings in the same query. This is what people mean by hybrid search in this context: combining exact, structured matching with approximate, meaning-based matching in one system, rather than running two separate databases and manually stitching the results together in application code.

The trade-off with bolting vector search onto a relational database this way is that the vector-search machinery — the specialized indexing structures that make similarity search fast at scale — is a secondary feature added to a system whose core architecture was designed around exact-match indexing and transactional guarantees, not high-dimensional nearest-neighbor search. For smaller collections or moderate query volume this is often perfectly sufficient, and it has a real advantage: you get vector search without adding an entirely separate database and the operational overhead of keeping two systems in sync. Purpose-built vector databases, by contrast, are architected around similarity search as the primary workload from the ground up, which tends to show up as better performance and more sophisticated filtering behavior at larger scale and higher query volume — though modern vector databases increasingly support structured, relational-style filters directly alongside vector similarity too, narrowing this gap from the other direction.

In practice, the decision between an open-source relational database extended with vector search and a dedicated vector database usually comes down to scale, how central similarity search is to the application, and how much operational complexity you’re willing to take on. An application where semantic search is a secondary feature bolted onto an otherwise conventional, transactional relational workload is a reasonable fit for the extension approach. An application where similarity search over large, high-dimensional embeddings is the primary access pattern — a recommendation engine, a retrieval-augmented generation pipeline — tends to be better served by a database built around that access pattern from the start.

So, Are Relational Databases Still Relevant?

Given everything above, the honest answer is that relational databases remain not just relevant but the default starting point for the majority of applications, precisely because most business data genuinely is relational in nature — customers who place orders, orders that contain line items, line items that reference products — and most applications genuinely do need the strong consistency guarantees ACID provides. The scaling challenges are real, but they only become the deciding factor at a scale, or with an access pattern, that a meaningful share of applications never actually reach. “Relational databases are dying” has been a recurring claim for well over a decade, and the reason it hasn’t materialized is that the specific problem relational databases solve well — structured, interrelated, transactionally consistent data — hasn’t gone away just because other tools now exist for different problems.

When to Actually Reach for One

In practice, a relational database is the right default when your data has clear, stable relationships between entities, when you need strong transactional guarantees because getting a write wrong has real consequences, and when the ability to ask new, unanticipated questions of your data through flexible queries matters more than raw write throughput at extreme scale. The moments to seriously consider an alternative are narrower and more specific: when your access patterns are dominated by traversing deep webs of relationships (a case for graph databases), when your data doesn’t have a consistent structure across records and rarely needs joins (a case for document databases), or when your scale and write volume genuinely demand horizontal distribution as a first-class design goal rather than an afterthought. For the large majority of applications that fall outside those specific cases, the relational model’s combination of structural clarity, query flexibility, and transactional reliability is still exactly the right tool for the job.