Posted on 4 mins read

I don’t know exactly when it happened. But if I had to guess, I’d say it was probably somewhere between 2000 and 2010. Somewhere in there, it was decided that understanding databases at more than a cursory level wasn’t really necessary to be a good software developer.

And in some ways, this is certainly true. You can create a Rails (or Elixir or Laravel or whatever) application today and build quite a lot of functionality without ever giving thought to the database underlying your models. If you want to query your data, you don’t use SQL - you reach for ActiveRecord, which is baked into Rails. You get to stay in the rarified world of Ruby objects, and never have to get your hands dirty with the complexities of the underlying database at all.

But at some point, your application will get more complex. You’ll need to pull and transform data from multiple models, and ActiveRecord won’t quite be up to the task. Sure, you could use Arel or something similar with more complex querying ability, but Arel will be of little use to you if you don’t know how to write a sound database query.

In other words, you need to know how to use SQL.


But really, the problem isn’t Rails or ActiveRecord. This isn’t DHH’s fault. The problem is that we have, as an industry, consistently undervalued the database, and we’ve been doing it for decades.

Case in point: The year was 1999, and I had just been hired to handle the “internal” software systems for a company that sold software to consumers. There was a “development team”, but technically, I wasn’t part of it, because my software was running the web sites and sales systems, not being burned onto CD’s and shipped to customers.

One day, the president of the company stepped into my office and asked me a question about the sales patterns of a particular product. He wanted to know how long it would take me to find the answer. When I replied “about a minute”, he was shocked. I pulled up a SQL query window and wrote a query to extract the data he was interested in, and had his answer for him in seconds.

He was mystified.

I was mystified at his mysticism. This guy was a genius developer, who had build amazingly complex software by himself. Yet he was amazed at my ability to hand-write a database query that, to be honest, wasn’t really all that complex. How could this be?

The answer, I soon realized, was that most software developers don’t think in terms of tables, joins, and queries. They live at a different level of abstraction, which is fine if your software doesn’t need to talk to a database.

That was true for the president of the company I worked for in 1999. It’s probably not true for you in 2017, where just about every system out there has a database behind it.


Abstractions like ActiveRecord have their place, and I’m not arguing against their use. I use ActiveRecord almost every day in my current consulting gig. It’s a great tool, and it gets better with each new Rails release. (Thanks, Rails core team!)

But abstractions are double-edged swords. They make simple things simpler, but they can also make hard things harder. When you’ve got a query that’s running far slower than you think it should be, the abstraction can get in your way and mask the true source of the problem.

What I am arguing for is this: Know what’s going on under the hood. Learn how SQL queries are constructed. Become familiar with inner and outer joins. Get up to speed on GROUP BY and HAVING clauses. Learn how indexes work. Discover the features and quirks of writing queries for the database system you’re using, whether it’s Postgres or mySql or SQL Server or (God forbid) Oracle.

In short: Learn SQL. You’ll be a better programmer if you do.