SQL will be turning 50 by the end of the decade. For a technology that’s still widely in use today, that’s quite the achievement — but it’s no surprise. Over the years, organizations have continued building their relational databases using SQL because of its extreme power, flexibility and reliability.
As in any industry over the course of five decades, plenty of challengers and alternatives have come and gone. One that comes up a lot is NoSQL: a broad category of wildly differing non-relational database technologies popular among the emerging tech class. Many wanted to jump on board when this approach was the next new thing, but times have changed. Many developers have realized NoSQL’s lack of security, lack of standardization and database inconsistency meant they needed tools to get NoSQL under control. And those tools looked a lot like SQL!
Take MongoDB. They’re working overtime to reinvent the wheel and incorporate their own SQL-like capabilities, but they’re going to need more hammers and chisels because that wheel’s still looking pretty square. They’ve implemented their own version of transactions, for example, but they’re crippled with ridiculous limitations — 16 megs of data per transaction, lasting 60 seconds at most... — that seriously limits the ability to work with large data sets.
And when Mongo introduced their connector for BI Components, it was originally written using Postgres itself! NoSQL companies know that one way or another, all roads lead back to SQL.
You’d think by now there’d be a better replacement for SQL. But instead, platforms like EDB Postgres build upon the power of SQL to offer users more robust tool sets with modern approaches like cloud compatibility. Here’s why SQL continues to thrive today, and why the NoSQL guys will inevitably come home.
Easy to Hire Staff
When something’s been around for nearly half a century, it’s become tried and true. Finding a DBA or programmer with experience working in SQL is as easy as throwing a stone: almost everyone knows it. If you’re working in any relational database, there’s an army of users out there who speak SQL and will have no trouble jumping between Oracle, SQL Server, or Postgres.
Choosing NoSQL for your database needs means you’re choosing a system that’s been around for less than half of the time that SQL has and everyone is different. There may be plenty of talented NoSQL users out there — but when you consider the number of people who have been deploying, developing and troubleshooting SQL databases since the 1970s, there's no comparison. In addition, most NoSQL databases are also stuck with their own proprietary interfaces so while you may know how to use MongoDB, that won’t likely help you if you want to move to Cassandra, Redis or Couchbase.
SQL Is Mature
Plenty of Tools to Work With
Your database is only as powerful as what you make out of it. For SQL, there aren’t just useful sets of tools built into platforms like EDB Postgres — there are many apps that put solutions right at your fingertips: managing columns, indices, relations and every other imaginable database task.
It doesn’t matter if you use Tableau for reporting, Quest for developer tools, or Cognos for business intelligence: when it comes to SQL, there are hundreds or thousands of different tools available for inserting, querying, extracting, replicating, and performance tuning. There’s an entire 3rd party ecosystem built to get the most out of SQL.
In the early days of NoSQL, developers were writing new applications that were designed to solve a single problem without much thought toward reusing the data in future systems. This meant that tools were generally not a priority other than the programming language used to develop that first application. Once those new applications became the new “legacy” that changed and tools for repurposing or reporting on that data became important. Unfortunately, due to the lack of standards in the NoSQL space, that was a problem. There’s no guarantee that your SQL-based tools are going to work with your data if you’re working with NoSQL. In fact, it is unlikely. MongoDB and Cassandra use their own non-standard APIs, locking you into each platform, each with its own custom set of tooling, with little room to escape. If you can tolerate that, good for you.
A Declarative Way to Access Data
SQL’s declarative queries have been refined for decades, with fully-optimized DB server engines built to deliver the information necessary that you’ve requested. NoSQL’s programmatic interfaces don’t behave the same way; you typically navigate to the data you need using their own non-standard interfaces or rely on one of their database specific query tools to access the data that ends up looking a lot like SQL. In many cases this means that the developer is responsible for optimizing the access to the data instead of relying on a robust query engine that has been tuned for the job.
Usable From All Programming Languages
Broad Vendor Support
From Microsoft to Oracle, most of the biggest names in tech rely on the SQL standard. Moving from one SQL solution to another isn’t the end of the world and doesn’t require ripping out most of your code.
That’s not the case with NoSQL. Because it’s usually built with non-standard APIs in mind, you’re usually locked into one vendor. That’s great for that particular vendor, but not great for your organization. Good vendors realize this, offering solutions that work best — and play best — with everyone.
At EDB, we offer everything from Postgres in the Cloud to a Tune-up Service for PostgreSQL in the Cloud to help organizations make the most of their data. Whether you’re building a database from the ground up or migrating from a legacy system, using SQL means you’re using the world’s most-preferred database language.