Asking About Data
SQL is understood as a way of asking questions to data rather than as a command.
Understanding SQL: How to Ask Questions of Your Data
When you build a service with AI's help or write code yourself, at some point you'll find yourself opening the Supabase dashboard.
At first, it seems enough to just create tables, check data, and tweak authentication settings. Then at some point, you encounter the SQL Editor in the left menu.
There are short sentences there.
SELECT, FROM, WHERE.
When you first see them, they look like code, or like commands. But SQL is not simply an incantation to manipulate a database.
SQL is closer to a way of asking questions of your data.
Data doesn't speak on its own
Accumulating data in a table and reading that data are different things.
When you click on a table in the Supabase dashboard, you see rows and columns. Numbers and letters. But in that state, you can't know anything. Who visited the most, which items are frequently viewed, what happened in the past week — the table doesn't answer those questions on its own.
To read data, you must first ask a question.
SQL is the language that structures that question.
Decide what you want to see — SELECT
SQL sentences usually start with SELECT.
SELECT name, email
FROM users;
This sentence means something like "show me the name and email columns from the users table."
SELECT determines "what will you see." Even if a table has ten columns, you can choose just the two you need right now. The rest have no bearing within this question.
This is not about filtering with conditions. It's about deciding which columns to keep on the screen.
SELECT is declaring that you will only look at the parts you want from the data.
Decide which record book to look at — FROM
FROM determines where to look.
A database has multiple tables. A table with user information, a table with order records, a table with posts. FROM points to which record book to open among them.
FROM users means something like "from the record book called users."
SELECT is the what, FROM is the where. With just these two, the most basic question is complete.
Narrow the scope of your question — WHERE
You rarely need all the data.
Most questions come with conditions. Users who joined today, items with completed orders, posts in a specific category. WHERE determines those conditions.
SELECT name, email
FROM users
WHERE created_at >= '2026-05-01';
This sentence retrieves the name and email of users who signed up on or after May 1, 2026.
Without WHERE, all rows of the selected table are targeted. With WHERE, the scope of the question narrows. The narrower it becomes, the clearer the answer.
The more specific the question, the more clearly the data speaks.
An attitude toward reading data
SELECT, FROM, WHERE. These three make up the most basic framework of SQL.
But this is not merely a matter of grammar. It's a matter of how you approach data.
Learning SQL is not about memorizing commands. It's about learning how to ask questions of data. Deciding what you want to see, pointing out where to find it, determining what scope to narrow it to — that structure is SQL.
If you felt confused when you first typed SELECT in the Supabase SQL Editor, that's only natural. You encountered the language of questions before you had sorted out what you wanted to ask.
Data doesn't speak on its own. It answers, little by little, only to those who are ready to read it.