Cloud Parts

Relational databases

Tables, SQL and transactions: the dependable default.

21 technologies on this page ↓
Live model
What you’re watchingThe app reads and writes the primary. The primary streams its changes to a read replica, and reporting queries go to the replica instead.

How it works

A relational database stores data in tables with a defined schema and relationships between them. You query it with SQL, join across tables, and group changes into ACID transactions so they all happen or none do. Managed services handle backups, failover, patching and read replicas that take read-heavy queries off the primary.

Think of it as

A meticulous accountant’s ledger. Every entry follows the rules, the books always balance, and you can ask it almost any question.

Reach for it when

  • Most business data: users, orders, inventory, billing
  • Data with relationships you want to query flexibly
  • Anything where correctness matters more than raw write speed

Think twice when

  • Billions of tiny writes a day with simple access patterns; consider key-value or time-series
  • Scanning petabytes for analytics, which belongs in a warehouse

A real example

An online store keeps customers, orders and order lines in PostgreSQL. Placing an order inserts the order and decrements stock in one transaction. Finance reports run on a read replica so they don’t slow checkout.

Technologies

Specific products, and what each does differently.

Distributed and cloud-native databases

Spread data across machines or split compute from storage.

What each provider calls it

AWS
RDS, Aurora
Google Cloud
Cloud SQL, AlloyDB, Spanner
Azure
Azure SQL Database, Azure Database for PostgreSQL
Open source & others
PostgreSQL, MySQL, MariaDB; also PlanetScale (hosted Vitess MySQL and Postgres) and CockroachDB (distributed SQL that speaks the Postgres protocol; proprietary licence since 2024), Neon (serverless Postgres, owned by Databricks), Vitess (sharding for MySQL, a CNCF project) CedarDB (Postgres-compatible, for transactions and analytics, proprietary) and Turso (a SQLite-compatible rewrite in Rust with concurrent writes, MIT; Supabase is acquiring the company); self-run Postgres usually adds Patroni for failover and WAL-G for backups, and on Kubernetes an operator such as CloudNativePG, Crunchy’s PGO or the Percona Operators runs the cluster

See it in a real stack

Architectures that use relational databases

In code · sql

BEGIN;
INSERT INTO orders (customer_id, total) VALUES (42, 129.00);
UPDATE inventory SET on_hand = on_hand - 1 WHERE sku = 'PUMP-ROD-7';
COMMIT;   -- both changes happen, or neither does

SELECT c.name, count(o.id) AS orders
FROM customers c JOIN orders o ON o.customer_id = c.id
GROUP BY c.name ORDER BY orders DESC LIMIT 10;

Worth exploring

Slides· September 2025How and Why Datadog moved from cloud-managed to self-managed PostgresNick Canzoneri, Datadog, at PGConf NYC 2025Slides from a talk on why a company running hundreds of Postgres clusters across several clouds left managed services for its own Postgres platform on Kubernetes, how it moved a whole region, and what got better and worse. The stack is Patroni (with ZooKeeper for leader election), WAL-G backups, a Helm chart rather than an operator, and Temporal workflows for automation. Useful before you weigh RDS-style convenience against running Postgres yourself.
Article· November 2024Kubernetes for databases: weighing the pros and consKate Obiidykhata, Percona, on the CNCF blog (first published on The New Stack)A short, high-level overview of why companies move databases onto Kubernetes (one platform across clouds and data centres, self-service, scaling, built-in failover) and the three ways to get there: a cloud DBaaS, a private DBaaS product, or an internal platform built from operators and monitoring. There is no technical depth or data. It is a CNCF member post by a Percona employee and ends by recommending Percona Everest, so read it as a vendor’s framing of the choice.
WebsiteDB-EnginesDB-Engines, provided by Redgate SoftwareA directory of hundreds of database systems with their data models, licences and features, which you can compare side by side. Its monthly ranking measures popularity (search results, Google Trends, Stack Overflow questions, job ads, LinkedIn profiles, posts on X), not quality or speed.
WebsiteThe Umbra Database SystemThomas Neumann’s group, Technical University of MunichThe research site for Umbra, the successor to HyPer and the basis of CedarDB: a feature overview and the full publication list with PDFs, from the CIDR 2020 paper “Umbra: A Disk-Based System with In-Memory Performance” onwards. You can try queries in the browser or pull a Docker image, but its terms allow only evaluation, not production use.
All resources →

Often confused with

Where it came from1970–2025

By the late 1960s, databases stored records as trees, like IBM’s IMS, released around 1968, or as networks of linked records, like the CODASYL model that Charles Bachman championed. Programs found data by following those links, so changing how data was stored meant changing the programs. In June 1970 Edgar F. “Ted” Codd, at IBM’s San Jose Research Laboratory, published “A Relational Model of Data for Large Shared Data Banks”. He argued that users “must be protected from having to know how the data is organized in the machine”, and proposed storing data as tables (relations) queried through one general language.

IBM was slow to commit, and until 1984 it treated IMS as its serious database. Its System R project in San Jose, begun in 1974, produced SEQUEL (later SQL), designed by Donald Chamberlin and Raymond Boyce, and set out to show that a relational system could have the full function and performance needed for everyday production use. At Berkeley, Michael Stonebraker’s team built Ingres. Relational Software, now Oracle, shipped Oracle V2, one of the first commercial SQL databases, in 1979, Codd won the Turing Award in 1981, and SQL became an ANSI standard in 1986.

Relational databases became the default home for business data, and open-source MySQL and PostgreSQL carried them into the web era. The cloud turned them into a service: Amazon RDS launched in 2009 as managed MySQL, and later systems such as Google Spanner (2012) and Amazon Aurora DSQL (2025) spread transactional databases across data centers and Regions.

Why it’s built this way

Tables of values instead of stored pointers
A main goal of Codd’s paper was data independence: programs should keep working when the storage layout changes. Relationships are expressed by matching values, such as a customer ID, not by links baked into the files.
Say what you want, not how to find it
A query describes the result, and the database chooses the indexes and join order. System R’s cost-based optimizer made that choice automatically; its inventor, Patricia Selinger, said cost-based optimization “made relational work”. It also means the same SQL keeps working as data and indexes change.
Transactions that happen completely or not at all
Orders, payments and stock levels must never be half-updated. System R logged every change so it could undo incomplete transactions after a failure, while aiming for performance comparable to existing systems.
One standard language across products
IBM’s backing moved the industry to SQL over alternatives like Ingres’s QUEL, and ANSI and ISO standards followed. No database claims full conformance to the current core standard, but skills and tools carry over between databases.

Timeline

  1. 1970

    Codd publishes the relational model at IBM San Jose

  2. 1974

    IBM’s System R project begins; SEQUEL, later SQL, is designed

  3. 1979

    Oracle V2, one of the first commercial SQL databases, ships

  4. 1986

    SQL becomes an ANSI standard, and ISO follows in 1987

  5. 2009

    Amazon RDS offers managed MySQL in the cloud

  6. 2012

    Google’s Spanner paper describes a globally distributed, synchronously replicated database

  7. 2025

    Amazon Aurora DSQL, a multi-Region distributed SQL database, becomes generally available

Sources17

Improve this page on GitHub