I don't need your query language

This post may seem a bit harsh, but I'm tired of SQL shaming that has somehow become a thing in the industry. I have a right to disagree, don't I?

Every year or so, a new general-purpose database engine comes out. And that's great! It can bring new valuable approaches, architectures, and tools (plus, building database engines is fun).

Often this new database engine comes with a new query language. And that's probably good, too. Or maybe it's not.

Simple and elegant

What puzzles me is that every time the authors claim that having this brand-new query language is somehow a strength. It's not. It's a weakness. Learning a whole new language just to query your database is a burden. I don't want to do that.

We already have a common ground language for general-purpose databases. It's called SQL. I'd rather use it with your database.

📝 I'm not talking about software that targets a specific narrow domain field. Having a separate domain language for specific use cases makes perfect sense.

Sure, your language is elegant. That doesn't help me. First, it's still easier to write a slightly longer query in SQL than to learn a new query language. Second, your supposedly simple language will become complex anyways — as soon as I try to solve real-world tasks with it. So why bother?

Better than SQL

Sometimes the authors of a new query language try to frame SQL as terribly complex. Let's take an example from one of these "post-SQL" databases. A comparison that, according to the authors, speaks for itself.

📝 I'm using a particular "post-SQL" database (without naming it) to illustrate my point here, because its landing page is a vivid example of SQL shaming. This is not a criticism of the database or its authors. I'm sure it's a great product.

FancyQL:

select Movie {
  title,
  actors: {
   name
  },
};

SQL (as the authors of FancyQL see it):

SELECT
  title,
  Actors.name AS actor_name
FROM Movie
 LEFT JOIN Movie_Actors ON
  Movie.id = Movie_Actors.movie_id
 LEFT JOIN Person AS Actors ON
  Movie_Actors.person_id = Person.id

SQL (as it may be):

select
  title,
  actors.name
from movies
  join movies_actors using(movie_id)
  join actors using(actor_id)

Hmm. Another example?

FancyQL:

select Movie {
  title,
  actors: {
   name
  },
  rating := math::mean(.reviews.score)
} filter "Zendaya" in .actors.name;

SQL (as the authors of FancyQL see it):

SELECT
  title,
  Actors.name AS actor_name,
  (SELECT avg(score)
    FROM Movie_Reviews
    WHERE movie_id = Movie.id) AS rating
FROM
  Movie
  LEFT JOIN Movie_Actors ON
    Movie.id = Movie_Actors.movie_id
  LEFT JOIN Person AS Actors ON
    Movie_Actors.person_id = Person.id
WHERE
  'Zendaya' IN (
    SELECT Person.name
    FROM
      Movie_Actors
      INNER JOIN Person
        ON Movie_Actors.person_id = Person.id
    WHERE
      Movie_Actors.movie_id = Movie.id)

SQL (as it may be):

select
  title,
  actors.name,
  (select avg(score) from reviews
   where movie_id = movies.movie_id) as rating
from movies
  join movies_actors using(movie_id)
  join actors using(actor_id)
where movie_id in (
  select movie_id
  from actors join movies_actors using(actor_id)
  where actors.name = 'Zendaya'
)

movies.sql

A bit verbose. But maybe SQL is not that complex after all? Otherwise, why would you paint it scarier than it really is?

Modern

Here is another common argument:

SQL was designed with 1970s businessmen in mind, and it shows.

True, SQL was designed in the 1970s. But how is that a weakness? Everyone knows SQL. All major database engines support SQL. SQL is expressive enough to solve any data-related task. SQL has a solid standards committee that maintains and improves it. What can your language offer besides being created in the 2020s?

I can go on, but I don't think it's necessary. My point is simple.

I don't need your fancy query language. I'd stick with SQL.

Maybe it's just me.

──

P.S. Interested in mastering SQL instead of learning yet another query language? Check out my book — SQL Window Functions Explained

★ Subscribe to keep up with new posts.