SQL should have died many times. Why is it still here?

This is the third and final article in the series The Silent Revolution of Data. Throughout the history of computing, few technologies have been declared obsolete as many times as relational databases.

The internet, large digital services, NoSQL, big data, cloud computing, and now, artificial intelligence. With each new wave, a similar narrative emerges: new needs appear, existing technologies reveal limitations, and new architectures are presented not just as alternatives, but as inevitable replacements for their predecessors.

Reality has been far less linear. More than fifty years after Edgar F. Codd's paper, relational databases continue to underpin corporate systems, digital applications, and analytics platforms. SQL has made its way through mainframes, client-server computing, the internet, open-source software, distributed computing, and the cloud. And technologies created outside the relational universe have, in many cases, ended up incorporating SQL interfaces or concepts close to those of the relational model.

In the early 2000s, the expansion of the internet brought significant challenges. Applications began serving millions of users, data volumes grew rapidly, and documents, events, messages, and other semi-structured data gained relevance.

New generations of key-value, document-oriented, column-family, and graph databases gained ground, later grouped under the broad and heterogeneous NoSQL movement. These were different technologies, pursuing distinct combinations of scalability, availability, flexibility, performance, and consistency.

The mistake was turning a discussion about architectural trade-offs into a dispute between modern technology and outdated technology. The relational model, SQL, and physical architecture are different concepts. The relational model describes a mathematically grounded, logical way of representing and manipulating information. SQL is a language inspired by that model, although it is not a perfect implementation of relational theory. Physical architecture, in turn, determines how storage, processing, replication, and distribution are implemented.

Nothing in the relational model requires data to reside on a single server. Likewise, using SQL does not mean reproducing the architecture of a 1980s database.

This distinction helps explain what happened next. Relational databases incorporated support for JSON, partitioning, parallel processing, columnar storage, replication, and distribution. At the same time, platforms that were originally non-relational began offering SQL interfaces. There was no simple replacement. There was specialization, coexistence, and convergence.

One of the reasons lies in the power of the declarative approach. In SQL queries, we predominantly describe the desired result, while the system determines most of the physical execution strategy. Indexes, join strategies, parallelism, and access paths can change without requiring the user to control every detail.

This abstraction remains extremely powerful. Spanner is an interesting example. Presented by Google in 2012 as a globally distributed database, it later evolved toward a relational interface. The title of a paper published in 2017 is itself revealing: “Spanner: Becoming a SQL System”.

This does not mean that Spanner is simply a traditional distributed database. Its architecture has characteristics of its own. But it shows that global scale, distribution, and SQL are not necessarily incompatible concepts.

The cloud deepened this separation between logical interface and physical infrastructure. Databases came to be consumed as managed services, while storage, replication, availability, and part of the operation became progressively hidden behind the platform.

The same happened with analytics. Modern data warehouses may use columnar storage, massively parallel processing, and distributed architectures very different from traditional transactional databases, while keeping SQL as one of their main interfaces.

In October 2026, the DB-Engines ranking still placed Oracle, MySQL, Microsoft SQL Server, and PostgreSQL in the top four positions. The indicator does not directly measure market share, revenue, or installations, but uses different public signals of popularity. Therefore, it does not demonstrate commercial dominance, but it does offer an indicator of the persistent relevance of relational systems in the technology ecosystem.

This does not mean that relational databases are suitable for every problem. Documents, graphs, time series, search engines, and other architectures can offer important advantages in certain contexts. Technological maturity does not mean using SQL for everything. It means understanding when to use it and when another approach is more suitable.

Now a new transformation emerges: generative AI. Language models can already turn natural-language requests into SQL queries, explain data structures, and assist in building analyses. This may reduce the need to write SQL directly in certain tasks, especially for business users. But it does not make SQL or the underlying databases irrelevant. It merely adds a new layer of abstraction.

And there is a fundamental difference here compared to previous abstractions. A query optimizer receives an operation whose semantics have already been specified and decides, predominantly, how to execute it. An LLM that receives a question in natural language must first interpret what the user actually wants to know and turn that intent into operations on the data.

This introduces a new dimension of uncertainty. An LLM can generate a syntactically perfect SQL query, execute it without errors, retrieve existing records, and still produce a business-wise wrong answer.

Consider a seemingly simple request such as “show the net revenue of this business unit”.

The meaning of net revenue depends on definitions. Which discounts should be considered? How should returns be handled? Which operations belong to the unit? Which period should be used? Is there an official corporate definition for the indicator?

The query can be technically correct and still answer the wrong question. This problem existed before AI. But generative systems can make it less noticeable because they present results in natural language, accompanied by convincing explanations.

The ease of the interface does not guarantee the correctness of the interpretation. We still need adequate data models, consistent semantic definitions, quality, lineage, access controls, and governance. To answer questions about balances, contracts, inventories, or transactions, an LLM also needs to consult sufficiently authoritative sources.

Many of them remain relational databases. Paradoxically, then, AI may increase, rather than diminish, the importance of structured, governed, and reliable data.

Something similar happens with vector databases. Embeddings and similarity search have become important components of many AI applications, but they do not automatically replace relational databases.

Finding semantically related documents is a different problem from retrieving transactions that meet exact criteria. In many architectures, the two capabilities coexist. Relational databases have also begun incorporating vector features, allowing different forms of information retrieval to be combined within the same platform.

Once again, evolution does not necessarily occur through the complete replacement of one technology by another.

There is a particularly interesting connection here with 1970. Codd sought to reduce the dependence of users and applications on the physical details of data organization. The relational model provided a logical abstraction. SQL added a declarative interface that made it possible to express operations without determining every physical execution path. The cloud later abstracted part of the operational infrastructure itself.

Now, generative AI is beginning to abstract even the formulation of queries. But this new layer is different. We are not just hiding technical execution details. We are delegating to the system part of the interpretation of the meaning of what we want to know.

And this changes the nature of the problem. The greater the distance between the user and the mechanisms that produce an answer, the more important reliability, traceability, observability, and governance become.

A seemingly simple answer can hide an LLM, retrieval mechanisms, vector databases, SQL queries, business rules, and various corporate systems.

Abstraction also redistributes responsibilities. The relational model reduced dependence on the physical organization of data. SQL transferred part of the execution decisions to the database management system and its optimizers. The cloud transferred part of infrastructure operation to providers. Now, AI-based interfaces are beginning to transfer part of the interpretation of requests to probabilistic models. Each layer makes certain tasks easier, but also creates new dependencies.

After more than four decades following the evolution of technology, I see in this trajectory a characteristic of truly lasting innovations. They rarely remain relevant because their original implementations survive intact. They remain because their abstractions stay useful while the technologies around them change.

The relational model did not remain relevant because today's databases work like the experimental systems of the 1970s. SQL did not remain unchanged either. Both evolved, incorporated new capabilities, and came to operate on architectures their creators could hardly have imagined. No technology has a guarantee of permanence. New data models, interfaces, and architectures will keep emerging.

But the history of SQL shows that a technology can stop being new without ceasing to be fundamental. Perhaps this is the main conclusion of this series.

Edgar F. Codd's great contribution was not simply putting information into tables. It was establishing a mathematical abstraction that helped separate the logical representation of data from the details of its physical implementation.

In 1970, we began abstracting part of the physical organization of data. Later, SQL helped abstract part of the navigation and execution. The cloud abstracted part of the infrastructure. Now, AI is beginning to abstract even the language used to request information.

But there is an interesting paradox: the simpler the interface becomes, the more sophisticated the invisible infrastructure needed to support it can become.

Interfaces change. Architectures change. We still, however, need to store information, relate it, preserve its integrity, understand its meaning, and retrieve it reliably.

The history of computing is not just a succession of technologies replacing one another. It is also the history of abstractions that survive because they continue to solve fundamental problems.

And the trajectory of SQL leaves a lesson that is especially relevant in the age of artificial intelligence: technological progress often makes complexity less visible. But making it invisible does not mean eliminating it, nor does it free us from the need to understand it.