SQL Query Tester — Practice SQL Online
Run SQL SELECT queries on sample tables directly in your browser. Practice WHERE filters, ORDER BY sorting, LIMIT, and aggregate functions like COUNT and SUM against realistic data. No install or signup needed, runs entirely in your browser.
⏱ 7 min read · Complete guide below
How to Use the SQL Query Tester
- 1Pick one of the sample tables — users, products, or orders — as your FROM target.
- 2Write a SELECT query with WHERE filters, ORDER BY, LIMIT, or aggregates like COUNT and SUM.
- 3Press Run (or Ctrl/Cmd+Enter) to execute against the in-browser engine.
- 4Read the result table, or the red error message if the syntax is off.
Worked Example: Building a Top-N Query Step by Step
Start simple: SELECT * FROM products returns every column and row. Narrow it to expensive items with a filter: SELECT name, price FROM products WHERE price > 50. WHERE runs first, keeping only rows that pass the test. Now rank them: add ORDER BY price DESC to put the priciest at the top, and cap the output with LIMIT 3. The finished query — SELECT name, price FROM products WHERE price > 50 ORDER BY price DESC LIMIT 3— returns the three most expensive products over $50.
The order clauses execute in is the thing to internalise: WHERE filters rows, then ORDER BY sorts what survived, then LIMIT slices off the top of that sorted set. Swap in COUNT(*) or AVG(price) to collapse many rows into one summary number instead. And remember the classic gotcha the FAQ flags — WHERE city = NULL never matches anything, because nothing equals NULL; you need IS NULL. Practising these against fixed sample data is the fastest way to build query intuition before you touch a real database.
The Logical Order a SELECT Runs In
SQL reads left to right, but it does not execute that way, and grasping the real order is the single biggest step toward writing correct queries. Conceptually the database starts with FROM(pick the table), then applies WHERE (keep only rows that pass the filter), then any grouping and aggregation, then ORDER BY (sort what survived), and finally LIMIT (take the top slice of that sorted result). This explains behaviour that surprises beginners — for instance, why a filter cannot reference an aggregate the way ORDER BY can, and why LIMIT without ORDER BY returns an arbitrary set of rows. Once this pipeline is in your head, building a top-N query step by step, as in the example above, feels natural.
Why Practising on Sample Data Helps
Learning SQL against a live production database is risky and slow; learning it against fixed sample tables is fast and consequence-free. Because the users, products, and orders tables here are small, static, and read-only, you can run a query, read the result, tweak a clause, and run it again in seconds — the tight feedback loop that builds real fluency. You can experiment fearlessly, since there is nothing to break and no data to corrupt, and because the data never changes, you can predict what a correct query shouldreturn and check yourself. Only SELECT is allowed, which keeps the sandbox safe and focused on the querying skills that make up the bulk of everyday SQL work.
Common SQL Pitfalls to Watch For
A handful of mistakes trip up nearly every SQL newcomer, and practising here surfaces them safely. The most famous is NULL comparison: WHERE city = NULL never matches anything, because NULL is not equal to anything — not even to itself — so you must use IS NULL or IS NOT NULL. Another is confusing WHERE and HAVING: WHERE filters individual rows before aggregation, while HAVING filters groups after it. A third is forgetting that LIMIT without ORDER BY gives an undefined selection of rows rather than a meaningful “top” set. Internalising these on sample data means you will not rediscover them the hard way on a real database.
SQL Query Tips
Use aliases for readability
Although aliases are not currently parsed, plan for them: SELECT COUNT(*) AS total_orders FROM orders. Aliases make result columns self-documenting, especially for aggregates.
Filter before aggregating
WHERE filters rows before aggregation runs. To filter after aggregation you need HAVING (not yet supported). For example: SELECT category, COUNT(*) FROM products WHERE price > 50 counts expensive items by category.
Combine ORDER BY and LIMIT
Top-N queries are common: SELECT * FROM products ORDER BY price DESC LIMIT 3 returns the three most expensive products. Always pair ORDER BY with LIMIT when you want a ranked subset.
Understand NULL behaviour
NULL is not equal to anything, including itself. In SQL, NULL = NULL is not TRUE — you need IS NULL or IS NOT NULL. This is a common source of bugs for new SQL developers.
Frequently Asked Questions
What SQL features are supported?
The tester supports SELECT with column lists or *, FROM a single table, WHERE with single conditions (=, !=, >, <, >=, <=, LIKE), ORDER BY with ASC/DESC, LIMIT, and aggregate functions COUNT(*), SUM, AVG, MAX, MIN.
What sample tables are available?
Three tables: users (id, name, email, age, city), products (id, name, category, price, stock), and orders (id, user_id, product_id, quantity, total, status). These are static in-memory tables — changes are not persisted.
Does LIKE support wildcards?
Yes. LIKE supports the % wildcard (matches any sequence of characters). For example: WHERE name LIKE '%son' matches names ending in "son". Case-insensitive matching is used.
Can I run INSERT, UPDATE, or DELETE?
No. Only SELECT queries are supported. The in-memory tables are read-only to keep the tool safe and predictable for practice without unexpected side-effects.
How do I run a query?
Type your SQL in the editor and press the Run button or use Ctrl+Enter (Cmd+Enter on Mac). Results appear in a scrollable table below. Error messages are shown in red if the query is invalid.
Is my query data sent anywhere?
No. All SQL execution happens entirely in your browser using a custom in-browser SQL engine. No data is uploaded to any server.
In what order does a SQL SELECT actually run?
Although you write SELECT first, the database processes clauses in a different logical order: FROM (choose the table), then WHERE (filter rows), then grouping and aggregation, then ORDER BY (sort the surviving rows), and finally LIMIT (take the top slice). Understanding this pipeline explains a lot of otherwise puzzling behaviour — such as why WHERE cannot reference an aggregate and why LIMIT without ORDER BY returns an arbitrary set of rows.
Why does WHERE city = NULL return no rows?
Because in SQL, NULL represents an unknown value and is not equal to anything — not even to another NULL. Any comparison with = NULL evaluates to "unknown" rather than true, so no rows match. To test for missing values you must use IS NULL or IS NOT NULL. This is one of the most common sources of confusion for people new to SQL, which is why practising it on sample data is so useful.
What is the difference between WHERE and HAVING?
WHERE filters individual rows before any grouping or aggregation happens, while HAVING filters groups after aggregation. For example, WHERE price > 50 keeps expensive products before counting, whereas HAVING COUNT(*) > 5 would keep only categories that end up with more than five products. WHERE cannot reference an aggregate function; HAVING is specifically for filtering on aggregate results. (This tester supports WHERE; HAVING is a concept to know for real databases.)
Why should I practise SQL on sample data instead of a real database?
Practising on small, static, read-only sample tables is fast and completely safe — you cannot break anything, corrupt data, or affect a live system, so you can experiment freely. The tight loop of writing a query, reading the result, and adjusting builds fluency quickly. And because the data never changes, you can predict what a correct query should return and verify yourself, which is much harder against a large, constantly-changing production database.
Can I practise INSERT, UPDATE, or DELETE here?
No — this tester supports SELECT queries only, and the sample tables are read-only. This keeps the sandbox safe and predictable, and it reflects the reality that reading and querying data (SELECT) makes up the large majority of everyday SQL work. Once you are comfortable with SELECT, WHERE, ORDER BY, LIMIT, and aggregate functions here, those skills transfer directly to a full database where you can also modify data.