SQL is Dead. Long Live SQL!
I have been in Enterprise IT for 30 years. Long enough to see many hypes come and go, and a graveyard filled with failed promises made by sales reps and consultants promising real, game-changing impact of technology innovations to businesses.
Here are some examples that were sold to us as kind of a holy grail, yet turned out to be mayflies or ended up in niches after their minute of fame.
But there are also opposite cases. Technologies that were pronounced dead decades ago still made it into the era of AI and they are happily alive today.
Most long-term predictions about technology adoption simply fail to come true.
There are many factors contributing, but one stands out. We have a notorious tendency to underestimate inertia in technology adoption, particularly in Enterprise IT.
This may be partly about human nature, but it’s mainly about the experience of professionals in Enterprise IT environments. Yes, IT has to deliver impactful innovation to the business to improve competitiveness and bolster growth. But the core function of IT leadership is to manage risk and optimize costs in a proper balance to keep the lights on. This involves both people and technology and goes far beyond system availability and cybersecurity.
How decisions are made in Enterprise IT
To give you a simple example: as a CTO, when selecting a programming language for a new project, I have to look well beyond the capabilities of the language itself. Other factors are even more critical in my decision-making. I need to look inside of my company and into the broader market to gain an understanding of how popular the language is. Will it be easy to hire developers for a given language?
For example, if I had to choose between JavaScript and Ruby for a new project in 2025, I’d quickly check that over 66% of developers know JavaScript, but only 6.4% know Ruby (a possible server-side alternative), according to the StackOverflow survey. In such a case, even if Ruby is a better option, I’d probably go with JavaScript. It’s not only that hiring is potentially easier, but with a larger community of developers, you can also count on the comprehensiveness of the ecosystem: tooling, support, availability of professional services companies and so on.
Then I need to look into the long-term trends. How long is language around? Is the adoption still rising, has it plateaued or is it already decreasing? Will the language still develop to absorb new trends and innovations? Will there still be support available in 5 or 10 years from now?
And this is where our story about SQL and its history really begins.
What is SQL?
SQL is a broadly used, standardized, predominantly declarative programming language with procedural elements with the purpose to define data structures, manipulate, query and control data. It is based on relational algebra and it significantly enhanced previous query and data manipulation techniques such as VSAM. A statement consists of clauses, expressions, predicates, queries and recursive sub-statements.
There have always been vendor-specific extensions and dialects, but the core of the language itself is compliant with the standard in all major implementations. Incompatibilities affect data types and more advanced constructs.
SQL is not perfect. It does not consistently follow its elegant mathematical foundations, it is not optimal for hierarchical and graph-oriented data, it never fitted well into the object-oriented paradigm. Generally it does not integrate smoothly with both object-oriented and procedural languages (this is where Object-Relational-Mapping, or ORM, comes into play). More complex statements can get awkward to write and to read and it is not efficient to write large, more complex logic entirely in SQL or PL/SQL.
That is why over time many alternatives have been proposed and several have become quite a success, e.g. graph-query languages and noSQL for key-value stores and document-oriented data.
However, most successful alternatives finally have plateaued in their niche and in fact we even see a retreat of some of those in favor of SQL over the last years. On the other hand, some of these concepts such as JSON or graphs have already been applied to newer versions of SQL, reducing the need for alternatives.
SQL is old, but it’s clearly the winner in this marathon.
The Origins of SQL
The origins of SQL date back to the early 1970s. In 1970, Edgar F. Codd published A Relational Model of Data for Large Shared Data Banks, introducing the relational model of databases.
It was the birth of RDBMS, an entirely new category of IT systems at that time, which now, 55 years later, is still amongst the top 3 globally (alongside IT infrastructure and ERP systems). RDBMS adoption itself was driven by the rise of ERP and SQL adoption goes hand in hand with it. Like twins, one cannot exist without the other.
Two major relational database system prototypes were created between 1974 and 1977. Those were Ingres, developed at UC Berkeley (UCB), and System R, created at IBM San Jose. Ingres used a query language known as QUEL, and it led to the creation of systems such as Ingres Corp., MS SQL Server, Sybase, PostgreSQL, Wang’s PACE, and Britton-Lee. On the other hand, System R used the SEQUEL query language, and it contributed to the development of SQL/DS, DB2, Allbase, Oracle, and Non-Stop SQL.
It was also in this decade that Relational Database Management System, or RDBMS, became a recognized term.
Standardization and Adoption of SQL
After nearly 10 years of R&D of SQL, the 1980s was the decade of commercialization and standardization of RDBMS. Several commercial database systems were launched in the 1980s. That includes Oracle V2 (1979), Sybase SQL Server (1984), IBM DB2 for Mainframes (1983, successor of System R), IBM Informix (1985), Microsoft SQL Server 1.0 (1987) and SAP DB (1988).
An important step was the adoption of SQL as the standard database language by ANSI and ISO in 1986 and 1987, respectively. This standard went through many iterations over time, with the latest revision in 2023.
Reasons for vendors buying into the standardization included expectations of a faster overall growth with a standard in this evolving market; fear of losing to competitors if not supporting the standard; ability to influence the standard and ecosystem benefits.
The early success of SQL did not come out of nothing. There was clearly a demand.
However, massive growth really only started from the early 1990s. It was caused by decreasing hardware prices, the rise of Client-Server architectures with UNIX and PC and the adoption of ERP. This was the decade of emergence of open source relational databases with MySQL (1995), PostgreSQL (1996) and MariaDB (1999).
Genealogy of relational databases is quite complex – details can be seen here.
Current Landscape and Outlook
TL;DR SQL is here to stay. And not only that. It is more alive than ever and it’s growing. This dinosaur has outlived and surpassed all of its modern competitors in popularity.
It is a perfect example that in the run, the concepts of technology adoption lifecycle and the Gartner Hype Cycle do not always apply. SQL has entered its “late stage” by all means of definition, but it’s growing faster than ever before. Example of Gartner Hype Cycle from 2018, where SQL was not even a category anymore (and is still not in 2025).
Over the past five years, SQL databases have not only endured but they’ve flourished. In the 2020 Stack Overflow Developer Survey, MySQL and PostgreSQL already ranked among the most used databases worldwide. By 2025, their lead has only widened. MySQL, PostgreSQL, Microsoft SQL Server, and SQLite now make up the top four databases used by professional developers, far ahead of any noSQL alternative. Despite years of predictions that “SQL is dead,” the data shows the opposite: SQL remains the backbone of modern software and data-driven systems.
Why is SQL alive again?
Here are my four hypotheses on why SQL is coming back big time. Feel free to challenge me on this – I’m very curious to hear your opinions.
Foundation
SQL was one of the first declarative languages (over the common procedural ones at the time). A declarative language lets you describe what you want rather than how to do it. This is very appealing to users, who are not very familiar with other programming languages. It is very easy to learn and apply (at least for basic use cases) and it has an enormous degree of flexibility at the same time, making it suitable for a very broad range of data access patterns (such as ad-hoc queries versus transactional data access and manipulation).
Maturity
Obviously, a technology, which has been developed and matured over such a long time can be considered very stable and complete. No decision maker takes a technology risk by choosing SQL.
Adoption
We have touched upon this in the introduction. The adoption levels of SQL grew over a long time, sometimes slower, sometimes faster, but by now it is the by far dominant player as a data access language. This position on its own further secures its future growth.
If we take a brief branch into the business theory of competitive advantage, we know that in markets based on a two-sided platform, the leaders have a massive competitive advantage. SQL-based relational databases comprise such a two-sided platform in the broader sense:
- Community (or multiple communities in the case of SQL, as they arrange around particular database systems) – includes the SQL users, developers and other professionals
- Industry – includes system vendors, professional services organizations, cloud service providers and other parties.
This is where strong networking effects kick in. A larger community will push growth of the ecosystem and the capabilities of the systems as the industry will want to capitalize on the size of the market. At the same time, the community will grow by itself, because the choice for a technology itself by the users or the organizations the users work for will also be driven by the size of the community to manage risk and ensure access to talent.
This effect is very strong, and it can even lead to platforms “sucking in” use cases for which they have not been built, such as graph and vector database extensions for relational databases.
Evolution
Like in biological evolution, we cannot predict any outside events in technology evolution. We can only adapt to them once they happen. It is not the strongest or fastest or biggest species, which has the best chances of survival in the long run. It is the one, which is best able to adapt to change. The SQL of 2025 is no longer the SQL of 1970.
SQL has incorporated important changes on its way, including big data and distributed systems (sharding and partitioning, distributed SQL databases, columnar storage and analytics), smooth integration into modern programming and AI languages, support for semi-structured and unstructured data (json, array types, xml), adaptation to real-time analytics, support for advanced analytics and ML (e.g. BigQuery ML, PostgreSQL extensions), integration with ai pipelines, in-memory processing, vectorized query execution and GPU-accelerated ML.
What’s next for SQL?
SQL has proven it can evolve faster than the predictions about its decline. As AI, vector search, and real-time analytics reshape how we build applications, SQL continues to adapt rather than fade. The next wave won’t replace SQL. It will expand it. SQL is the database of choice for AI. We’ll see deeper integration with AI-driven data processing, vector-native extensions, and cloud-native scaling that makes databases more dynamic than ever.
For those of us who have watched decades of hype come and go, SQL’s future feels both familiar and new. It’s still the language of data—but now it speaks the language of intelligence, too. I would be interested to hear your feedback on my hypotheses and the future of SQL.
Personally, I believe that SQL is still the future and that’s why we are building Vela. Vela is a modern Backend-as-a-Service Platform built on Postgres. This way we can show how Postgres keeps SQL relevant for today’s cloud and AI workloads.
