Will SQL just die already?

With tons of new No-SQL database offerings everyday, developers & architects have a lot of options. Cassandra, Mongodb, Couchdb, Dynamodb & Firebase to name a few.

Join 33,000 others and follow Sean Hull on twitter @hullsean.

What’s more in the data warehouse space, you have Hadoop, which can churn through terabytes of data and get you results back before lunchtime!

So when I stumbled on this article SQL is 43 years old, I was intrigued.

Answer the questions you haven’t thought of

No-SQL databases are great if you know how you want to access the data. Users come from the users table, and that’s that!

But if later on you want to ask questions like, which users watched this video, which users are active, which users spent $100 in January? These questions may not be possible because NoSQL can’t join those other tables.

Relational databases shine when you need to aggregate your data, reorganize it, or ask unanticipated questions. And aren’t those most of the interesting questions?

Also: Top serverless interview questions for hiring aws lambda experts

Big Query, Redshift & even Hive speak SQL

I wrote that despite recent popularity in Hadoop, Redshift seems to be eating their lunch. And what would you know, surprise surprise, Amazon’s newish data warehousing solution, speaks SQL! What’s more there’s Apache Hive, which allows you to query Hadoop with, drumroll please… SQL!

Bigquery is the other major bigdata offering from none other than Google. And it too uses SQL!

Related: Which engineering roles are in greatest demand?

Still dominant

If you look at Stackoverflow’s developer survey, you’ll see that SQL is the second most popular language. Why might that be? For one thing it’s simple to learn. Enough that even business users can write simple requests, join & aggregate data.

Read: Can on-demand consulting save startups time & money?

Rugged, Proven & Open

SQL having been around so long is a fairly open standard. Sure there are extensions of it, but most of the basic stuff is there in all the products. That means you learn it once, and can interact with databases across the spectrum. That’s a win for everybody.

Also: 30 questions to ask a serverless fanboy

Business users can write it

Another under appreciated feature though is that basic queries are easy to write. They don’t require complex syntax like a hadoop job, or your favorite imperative programming language. The queries are readable, almost english-like sentences.

Given all that, it seems SQL is likely to be around for a long time to come!

Also: What can startups learn from the DYN DNS outage?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Also published on Medium.

  • ellisgl

    There are some no-SQL db’s out there that do support joins. But still are far off from production in my view. (Ex: http://orientdb.com/orientdb/ – this one problem I have with it: https://github.com/orientechnologies/orientdb/issues/771)

    “Another under appreciated feature though is that basic queries are easy to write. They don’t require complex syntax like a hadoop job, or your favorite imperative programming language. The queries are readable, almost english-like sentences.”

    And yet people are still gun-ho about using ORMs (shudders – SQL is fairly simple, and if you know what terms to use, google will supply lots of stuff!).

    • Joshua Dickerson

      I don’t think ORMs are used for readability so much as they are for extensibility. To make a change in SQL, I need to rewrite the query or use some regular expression to do some string manipulation. Using an ORM, I can access an object and remove a SQL construct by removing that property of the object. I know that’s not your main point, but I just wanted to make note of my view as a developer.

      • http://www.iheavy.com/blog/ Sean Hull

        Thx Joshua.

        Jeff Atwood says ORMs are the Vietnam of Computer Science


        That’s an apt metaphor in my view. It seems like a good idea to start with, but you can never get out, and it just gets uglier and uglier.

        • Joshua Dickerson

          They have their place but I generally am not a fan of them. I don’t mind writing another query.

        • ellisgl

          Yeah, in the beginning (my first run in with ORMs years ago in PHP), they seem awesome. “I can write a query and I can run it on any database!”. Then the first thing you figure out, you are running one DB. Sure, you could switch DB’s later on. Then you find out about the the limitations of ORMs and the issues they actually generate when you start doing more complete things than “SELECT `whatever` FROM `sometable`”.

      • https://www.facebook.com/sreeramamek Sree Ramakrishna

        Yes, the ORMs too have advantages. As you said, it’s not the main point here.

        • http://www.iheavy.com/blog/ Sean Hull

          Well… yes I suppose.

          • https://www.facebook.com/sreeramamek SreeRamaK

            Though it is a great article on SQL, I would say, your points add more value by complenting SQL with ORM and NoSQL.
            Because things are becoming more smart, more sacalable, multiple technologies for a single enterprise solution. Eg. OLTP and OLAP exists together in an enterprise. SQL, RDBMS are a kind of heart to the oltp application. NoSQL is a kind of heart to OLAP applications.
            And many enterprise web applications (java or c-sharp) are developed using ORM.
            SQLexists alone or with ORM or NoSql in webapplications, cloud, real time transactions, bigdata applications and IoT.

  • ellisgl
    • http://www.iheavy.com/blog/ Sean Hull

      That link worked. Yes interesting trend.

      A 10,000 feet this looks like “muddying the waters”. Which I think is a bad idea.


      In fact I’m going to write a *new* post about this right now. Will followup with a link!

      • ellisgl

        Well that was major issue was “I only want to select certain things, don’t give me back all the documents!”. The idea of that DB is that you have a hybrid Document & Graph, which give you an expanded version of relationships and you can have free form documents. Of course you can do this in SQL, but then you have a bunch of tables covering lots of use cases. Of course, having more tables that are locked in to a format does free you up from stupid typos (Get errors instead of just useless docs which you might not see the issue till way down the road).

  • http://crowfly.net/sandro David Link

    Great article on SQL. Younger developers often learn noSQL first and love it. But as you say Sean, nothing beats SQL for relational data and ad hoc queuing. @ellisgl:disqus I like your ideas of dealing with lists in SQL. Have a look at my vlib.datatable module. You may like it: https://github.com/dlink/vlib

    • http://www.iheavy.com/blog/ Sean Hull

      Thx David. Yep. SQL just keeps on truckin! haha.

      How are things with you btw?

    • ellisgl

      Are you talking about my PDO wrapper: https://github.com/ellisgl/GeekLab-GLPDO ?

      • http://www.iheavy.com/blog/ Sean Hull

        Not familiar but I’ll take a look.

  • Jeff

    All very good points regarding the use and relevance of SQL. It’s good to see that not everyone is running to noSQL just because it’s “cool” tech. We use SQL and noSQL selectively in projects based on using the best tool for the job.

    • http://www.iheavy.com/blog/ Sean Hull

      Thx Jeff. Yep I like that approach too. Use the best tool for the job.

  • http://www.iheavy.com/blog/ Sean Hull

    hehe 🙂

  • http://www.iheavy.com/blog/ Sean Hull

    I see what you mean, Sree.