SQL: The Technology That Never Left Is Back

What "SQL is back" actually refers to

The phrase describes a pattern, not an event: a wave of document and key-value databases marketed themselves as NoSQL in the 2000s and 2010s, arguing that rigid schemas and joins could not scale. A decade later, most of those same systems and their successors added SQL or SQL-like query layers back on top. MongoDB offers a pipeline-based aggregation framework plus separate connectors that let BI tools query it with SQL, Cassandra has CQL, and distributed engines such as CockroachDB, Trino, and Spark SQL expose SQL as the primary interface over partitioned or columnar storage.

So "SQL is back" really means: the query language won, even when the underlying storage engine changed. Developers wanted declarative set-based queries, standard tooling, and predictable semantics more than they wanted to escape the relational model.

Why it never actually left

While NoSQL adoption grew, PostgreSQL, MySQL, and SQL Server kept handling the bulk of transactional workloads, financial systems, and reporting pipelines. Business intelligence tools, spreadsheets, and reporting software are built around SQL, so any database without it needed a translation layer eventually. The ANSI/ISO SQL standard also kept evolving during that period, adding window functions, recursive common table expressions, and native JSON operators, which closed much of the gap that NoSQL databases were trying to fill.

Relational databases did not stand still. PostgreSQL added a binary JSON type (JSONB) that stores documents efficiently and supports indexing, effectively letting a relational database behave like a document store when needed, without giving up transactions or joins.

How this works internally

A modern relational engine separates the query language from physical storage. The planner parses SQL into a logical plan, then the optimizer chooses a physical execution strategy based on statistics, indexes, and cost estimates. That separation is exactly what let PostgreSQL and similar engines bolt on new capabilities without changing the language:

• JSONB storage keeps a document in a decomposed binary format instead of raw text, so a specific key can be indexed with a standard B-tree expression index, or the whole document can be indexed with GIN for containment queries, instead of forcing a full scan.
• Partitioning and parallel query let a single logical table span multiple physical segments or workers, which is how relational engines absorbed some of the horizontal-scale story NoSQL offered.
• MVCC (multi-version concurrency control) keeps transactional guarantees intact even as these features get added, so SQL's ACID semantics are not traded away for flexibility.

The result is a single query language that can touch strictly typed columns, semi-structured JSON, and, through open-source extensions such as Apache AGE, graph-shaped data, without the application switching drivers or query dialects.

A small example: relational and JSON in one query

This example stores a normalized orders table alongside a JSONB column for variable attributes, then queries both with standard SQL in PostgreSQL:

CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  customer_id INT NOT NULL,
  status TEXT NOT NULL,
  metadata JSONB
);

INSERT INTO orders (customer_id, status, metadata)
VALUES
  (101, 'shipped', '{"carrier": "ups", "priority": true}'),
  (102, 'pending', '{"carrier": "usps"}');

-- Index a specific JSON key for fast lookups
CREATE INDEX idx_orders_priority
  ON orders ((metadata->>'priority'));

-- Query combines a normal WHERE clause with a JSON path lookup
SELECT id, customer_id, metadata->>'carrier' AS carrier
FROM orders
WHERE status = 'shipped'
  AND metadata->>'priority' = 'true';

The metadata column can vary freely between rows, the way a NoSQL document would, while customer_id and status stay strongly typed and indexable the normal relational way.

Trade-offs to weigh

SQL's return to the center does not mean document and key-value stores lost their reason to exist. Each model still fits different access patterns:

• Relational SQL is strongest when data has clear entities, relationships, and integrity rules that must hold (orders, accounts, inventory).
• Document stores still fit workloads where the schema genuinely varies per record and queries mostly fetch whole documents by key, rather than joining across entities.
• Distributed SQL engines (CockroachDB, YugabyteDB, Trino) trade some write latency for horizontal scale and SQL compatibility, which suits teams that need scale without abandoning existing SQL tooling and staff skills.

Choosing SQL-on-everything does not remove the need to think about consistency models, latency, and how the data will actually be queried. A JSONB column inside PostgreSQL is still subject to the same disk I/O and locking behavior as any other column.

Common mistakes

Teams that move back toward SQL-centric designs, or that start bolting JSON onto relational tables, tend to repeat the same errors:

• Dumping everything into a single JSONB blob instead of extracting fields that are queried often into real columns, which defeats indexing and planner statistics.
• Skipping indexes on JSON paths, then being surprised that JSON queries are slower than equivalent relational ones.
• Assuming a SQL interface on a distributed system (Trino, Spark SQL) gives the same transactional guarantees as a single-node relational database; many of these engines are built for analytics, not OLTP consistency.
• Over-normalizing data that is genuinely variable per record, which recreates the exact rigidity problem NoSQL was trying to solve in the first place.