SQL for people who do not program

SQL sounds like something for the IT department. Yet it is the language almost every business database answers in, including the ones behind your ERP, your till and your webshop. And the basics are smaller than you think.

You do not have to write it yourself. But if you can read a little of what is being asked, you also understand better what happens in a report, and where it can go wrong.

What SQL is

SQL is a language for asking a database questions. Not a program, not a product. A way of asking.

At its core a database is a collection of tables: one with customers, one with invoices, one with articles. Every row is one thing, every column one property. SQL tells the database which rows and columns you want to see, and how.

The four words you need

The vast majority of questions use only four words.

SELECT says which columns you want to see. FROM says from which table. WHERE says which rows. GROUP BY says how you add up.

An example: revenue per customer in 2026.

SELECT customer, SUM(amount) FROM invoices WHERE year = 2026 GROUP BY customer

Just read it as a sentence. Show the customer and the sum of the amount, from the invoices, only 2026, per customer. That is all it is.

The fifth word: JOIN

It gets interesting when you bring two tables together. Your invoices know which customer number they belong to, but not which region that customer is in. That information sits in the customer table.

JOIN puts those two tables side by side based on what they have in common, usually a number. Then you can ask for revenue per region, even though the region is on no invoice anywhere.

This is also where it usually goes wrong. Join on something that is not unique, like a customer name, and rows quietly drop out or get counted twice. The query simply gives an answer, just a wrong one. That is the same problem as in the article on the data model, and it is why a unique number per customer is worth so much.

So what is PostgreSQL

This is where the confusion usually comes from. SQL is the language. PostgreSQL is a database that speaks that language, just like Microsoft's SQL Server, MySQL and a range of others.

Compare it with British and American English. Everyone understands each other, the basics are the same, but some words and expressions differ. The four words above work everywhere. The details do not always: asking for the first ten rows is written differently in SQL Server than in PostgreSQL.

When someone says "plain SQL", they usually mean one of two things: the language itself, or SQL Server, because that is the default in many Microsoft environments.

Why I work with PostgreSQL

Three reasons, and none of them is that the others are bad.

It is open source. You pay no license for the database itself, only for the place where it runs. For the volume of a small company that is a big difference.

It is available everywhere. Dozens of providers host it for you, including Neon, which I use myself. You are not tied to one vendor.

And it handles JSON well, the format most APIs return their data in. That makes it easy to store data from a CRM or ERP raw first and only then pour it into tables.

SQL Server is an excellent choice if you are already deep in the Microsoft world and have the license for it. Power BI works equally well with both.

What an owner gets out of this

You do not need to write queries. It does help to know that every number in your report was once a question in this language, with a WHERE that decides what counts and a JOIN that decides what hangs on what.

If a number is wrong, the mistake almost always sits in one of those two. And with a little SQL you can check yourself whether revenue in the database matches revenue in your report. That is the check the previous article was about.

The claim

SQL is not a programming language for specialists. It is the language your data answers in, and anyone who can read the four basic words can also see where a report asks the wrong question.