Learn SQL by Typing It: Three Browser Database Terminals Compared

SQL is a skill you acquire by running queries against data and being wrong a lot. Reading a tutorial produces recognition ("yes, that is a LEFT JOIN"); typing sixty queries produces recall, and recall is what an interview or a production incident actually tests. The problem for beginners is that running queries traditionally starts with installing a database, and "install PostgreSQL" is where a lot of SQL journeys quietly end.

Browser-based database terminals remove that step. Below is a practice path through three of them, each free and signup-free, and each covering a different layer of the skill: the SQL language itself, the psql client you will meet at work, and the document-database alternative for contrast.

Layer 1: the SQL language

The SQL Terminal Simulator is a guided path of 13 lessons against a small commerce dataset: customers, orders, order_items, products. It starts at SELECT and ends at common table expressions and window functions.

The progression, with one example of each rung, all runnable in the simulator:

-- reading
SELECT name, country FROM customers;
SELECT * FROM customers WHERE country = 'Germany';
SELECT * FROM customers ORDER BY signup_date DESC LIMIT 5;
SELECT DISTINCT country FROM customers;

-- aggregating
SELECT COUNT(*) FROM customers;
SELECT country, COUNT(*) FROM customers GROUP BY country;

-- combining
SELECT o.order_id, c.name, o.status
FROM orders o
JOIN customers c ON c.customer_id = o.customer_id
WHERE o.status = 'shipped';

The rung after that is where the dataset earns its keep: revenue does not live in one table. There is no orders.total column, so answering "how much has each customer spent" forces the three-way join that real schemas force on you:

SELECT c.name, SUM(oi.quantity * p.price) AS revenue
FROM customers c
JOIN orders o  ON o.customer_id = c.customer_id
JOIN order_items oi ON oi.order_id = o.order_id
JOIN products p ON p.product_id = oi.product_id
GROUP BY c.name
ORDER BY revenue DESC;

The JOIN versus LEFT JOIN pair is the single most valuable thing to drill. Two classic bugs account for a large share of wrong query results in application code: an inner join silently dropping rows, and an aggregate double-counting because of join fan-out. You learn to smell both by writing the queries and counting the rows that come back.

An implementation detail worth knowing, because it affects what you can type: single-table queries are evaluated live against the in-memory dataset (SELECT, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT and the common aggregates), so you can experiment freely there. The multi-table joins, subqueries and window functions are the guided lessons' specific queries, and their results were captured verbatim from a real PostgreSQL instance, so what you see is exactly what Postgres returns, down to the numeric formatting. Arbitrary ad-hoc joins are not interpreted; for free-form join practice, graduate to a real database (more on that below).

Layer 2: the client is a skill too

Something SQL courses tend to skip: at work you often get a connection string and a terminal, and the tool at the other end is psql. Knowing SQL but not the client leaves you fumbling exactly when someone is watching.

The psql Terminal Simulator drills the client itself across 8 lessons. The meta-commands first:

\l          -- list databases
\dt         -- list the tables in your search path
\d orders   -- describe one table: columns, types, indexes
\di         -- list indexes
\x          -- toggle expanded output (wide rows become readable)
\timing     -- toggle per-query timing

\d is the one you will use daily: it answers "what is actually in this table" without leaving the terminal. \x is the one that saves you the first time a query returns twenty wrapped columns. (In real psql, \q quits; the simulator politely declines that one.)

The later lessons walk the workflow that separates "can query" from "can investigate a slow query", using a deliberately large big_events table:

EXPLAIN SELECT * FROM big_events WHERE user_id = 42;
-- Seq Scan on big_events ...

CREATE INDEX idx_big_events_user ON big_events (user_id);

EXPLAIN SELECT * FROM big_events WHERE user_id = 42;
-- Bitmap Index Scan feeding a Bitmap Heap Scan

In this prepared dataset the plan flips once the index exists; on a real system the planner weighs table size, selectivity and statistics, and sometimes correctly ignores your new index, which is its own lesson. EXPLAIN ANALYZE then shows actual timings, and a transactions lesson (BEGIN, COMMIT, ROLLBACK) covers the day you want to try a risky UPDATE with an exit hatch.

Watching a plan change because of something you did teaches more about indexes than any diagram of a B-tree.

Layer 3: the document side, for contrast

You will meet MongoDB, or something shaped like it, eventually. The mental model is different enough that learning it by contrast, right after SQL, is the cheapest time to do it.

The MongoDB Terminal Simulator covers the shell in 10 lessons: find() with query operators, projections, sort/limit/skip paging, inserts and updates, and the aggregation pipeline. The instructive part is seeing familiar questions wearing new syntax:

// SQL: SELECT name, country FROM customers WHERE country = 'Germany';
db.customers.find({ country: 'Germany' }, { name: 1, country: 1, _id: 0 })

// SQL: SELECT country, COUNT(*) FROM customers GROUP BY country;
db.customers.aggregate([
  { $group: { _id: '$country', count: { $sum: 1 } } }
])

The aggregation pipeline is where the model clicks or does not: you express the computation as an ordered sequence of stages ($match, then $group, then $sort), each transforming the stream. Some people find it clearer than SQL. Almost everyone finds it clarifying to hold both models, because half of understanding a tool is knowing what it is not.

How to actually use these

A workable schedule: one layer per week, fifteen minutes a day, always typing rather than reading. Do the guided lessons once, then come back without the guidance and try to reproduce the queries from the lesson titles alone. Recall, not recognition, is the goal.

Then graduate: install Postgres locally or grab a free hosted instance, load a real dataset, and take the muscle memory with you. The simulators are the on-ramp, not the destination.

Disclosure: I help build these simulators; they are part of 50+ free DevOps games and simulators. For more practice beyond them, SQLBolt and PostgreSQL Exercises are excellent and free, and SQL Murder Mystery is the most fun anyone has ever had with a schema.