SQL turns 50 this month -- why is it still going strong? [Q&A]

Data management language SQL (originally published as SEQUEL) first appeared in May 1974, so this month marks its 50th anniversary.

We spoke to Peter Zaitsev, founder at Percona, to find out why SQL has survived for the last 50 years, and is still the third most used language for programmers and software developers according to Stack Overflow.

BN: Why was SQL successful at the time, and why is it still used today?

PZ: I think SQL was successful because it gave us a data language -- a set of tools that could be used to work with and manipulate data -- and once people started using it, they were more likely to continue using it. Data is very, very sticky, it has its own gravity and once you are in its orbit then you are going to carry on with that way of working. It's hard to move away from something like that which is working. If your data is in a database, which uses SQL, well, then you're kind of stuck with using SQL.

SEE ALSO: Get 'PowerShell 7 Workshop' (worth $35.99) for FREE

It's also interesting to consider whether SQL is a programming language, which succeeded in its original intent. The original intent for this language was not around whether you have a particular database, but whether you have a terminal to access your computing resources like data. In that environment, you would ask questions, and those questions would be very human readable, using commands and the like. It worked for that environment, but then it got adopted more broadly, even beyond developers and data specialists.

SQL is still very popular today, and it is ranked as the number #3 language that professional programmers use according to Stack Overflow. However, there are a lot of companies that are trying to attract people away from SQL itself. They have had success around databases and making them really simple -- take MongoDB, for example. MongoDB lets you store data outside traditional database designs in JSON documents and you don’t need to set up schemas or tables yourself. It provides everything as an extension of its programming language, so you can say, "You don't need to learn SQL, just use our stuff, our object-relational mapping tools, and you will be fine!" This means that a lot of SQL is hidden away, it's not written by humans directly. You can see this with data visualisation tools as well like Tableau or MetaBase, where they will create SQL for you to generate reports and data analytics.

SQL is still used today, SQL is still at the heart of all this work around data, but a large part of this today is behind the scenes. Having said that, you need to know your SQL when something goes wrong or you are not getting the results that you want. If you don’t then you won't be able to diagnose what the real problem is and fix it.

BN: Why do we still rely on SQL so much?

PZ: SQL made it easier to standardise things around data. SQL made it easier to work with data because it became a standard way to work with data, where you did not have to implement all sorts of different connectors or integrations to work with your data, you could just use it. People don't want to invest their time in making stuff work in the first place, they want to invest time where they can get things done.

SQL is also about more than the commands -- it provides you with the way to get those commands and requests made through following the protocol. For example, many developers use MySQL today, but they are thinking about moving to PostgreSQL -- moving from one database to another is hard if you don’t know the protocols and how things work. Understanding SQL does make it easier to move, and a lot of developers are now looking at how to use PostgreSQL not just to speak SQL, but often speak SQL through the free PostgresSQL protocol, as it simplifies onboarding.

BN: How has SQL changed over time?

PZ: What I think is interesting is that SQL is kind of a lens language -- it shows you how people prefer to work at a given time. I mean, for ages SQL has been good at figuring out how to solve modern problems, from when it was first developed through to today. For example, a couple of decades ago, XML (extensible markup language) was very big, right? In response, things like XPAth and Xquery were introduced into the SQL standard so that people could work with XML data. Then SQL added GIS (geographic information system) data, because location data had become more important. Over the next few years, everything moved over to JSON, which pretty much replaced XML for working with structured documents. So SQL added a lot of features to work with JSON objects stored inside a database.

When you talk about SQL as a language, we should talk about SQL as a family of languages. Because if you think about , for instance, Python, well, it's one language, right? But every database implements SQL differently. While SQL is a standard, I'm not sure if anybody implements that standard in the same way. All the databases, they tend to add some additional extensions that suit what that database is aimed at. So there may be some differences in how Postgres works around SQL to MySQL and SQL, and they will be different to Oracle. For example, you may find that things work differently in terms of transaction isolation in MySQL and Postgres even if you run the same queries on both of them. This can lead to different results. So I think that is an example of how good SQL has been at being successful over time, but it is also a nuance that we have to understand.

Even if we have the same language or a very similar version, it will still come down to the implementation side. This is where things can be very different. We can see all the different database teams out there innovating around SQL, and then the best ideas are copied by other vendors. Eventually, those successful implementation decisions will make it into the standard, so everyone can benefit.

BN: Will SQL be replaced by another option?

PZ: There are so many different databases that have been launched -- over the past few years, we have seen all the NoSQL databases that came out to solve their specific problems. They broke away from the relational model to solve those problems, and a lot of them started out not supporting SQL. They wanted to work in their own ways. But a lot of them added SQL support, or SQL-like features, because they recognised that this was one of the best ways to get people working with your database. They already know SQL, so it gets them started faster, and removes that barrier to entry.

Today, we have all these new AI applications, so you see more databases aimed at AI, at vector search and all the major databases are adding these functionalities as standard using extensions. It is the same model that SQL has had around supporting new requirements, and becoming part of the standard over time. It has kept SQL relevant.

Alongside this you have to look at what is going on around SQL as a protocol.The communication protocol is largely commoditized and there is not a lot of innovation happening there. It works so people don't want to touch it, because if you choose now to implement a different protocol, that means you have to develop your own programming language, build out a community to support that language, develop and maintain a roadmap, which is a lot of heavy lifting. There are a few communities that have built their own protocols like Clickhouse, which has a native protocol because they wanted to do certain things differently, but they tend to support SQL as well. This makes it easier for those that want to go down that certain route to have that option, but having SQL as an option as well keeps that project or product available to a wider audience. For a lot of databases, SQL is going to continue as the standard that they use, and I don't see anything replacing it.

BN: What does the future hold for SQL?

PZ: It is interesting to look at how technology progresses. More and more areas of technology have become ‘good enough’ that they just work and they can then be used for a very long time. In my opinion, you can imagine how many systems that are being created right now that will still be working in 50 years time. I think that is always a good question to ask: "Hey, what does being in production really mean?" because we have to think about what we write in terms of code and functions, versus what we are using to write those new applications. We should not be thinking about using version 3.2 of something versus 3.4, but why something exists, and why it will be needed in that long a timeframe. That is a much harder question to answer, because some of those applications won't last that long and others will get there without that kind of planning ahead.

Today, we have this great transformation going on, where we have AI changing our software development processes, and the potential scope for software engineering. We can use AI to generate code, but it is not completely accurate, so we are still in the really early stages here and we have to decide what role we want for humans to be involved in putting that code together.

For SQL, AI can create that code and write what it thinks you want the query to be. But that does not mean that the query will be right, or that it will work. It will look right, and it may run, but it may not run efficiently or produce the results that you want to get. So, these tools should be looked at as just that -- tools. You will still have to know SQL in order to understand what the AI is giving to you as an option, so that you can judge it in the right way. AI might hide some of what is going on around SQL, but it will still be the foundation for a lot of these new applications that we use.

Image credit: dizain / Shutterstock