The quick read: SQL
SQL is easiest to reason about when the experiment is small. Put the code in the page editor, add input only if the snippet reads input, and run it once before you start editing around the problem.
The SQL page uses a browser SQL engine for quick query practice, so the database is temporary and recreated for the exercise. We chose that setup so the page can answer quick syntax and behavior questions without pretending to be your whole development machine.
ANSI SQL is the shared center, but every database adds dialect details around dates, strings, limits, and type conversion. Tiny repros are honest. They either show the issue, or they tell you the issue lives somewhere else.
Sharp edges
The runner is not a production environment. It will not carry durable state between serious sessions, and it should not be asked to handle vendor-specific functions, huge tables, indexes, users, and transaction isolation behavior. Good. Boundaries make bugs easier to see.
The sweet spot is SELECT, JOIN, GROUP BY, HAVING, subqueries, and small schema experiments. If your example needs a package manager, a database full of private rows, a web server listening on a port, or special build flags, move it to a local workspace before you draw conclusions.
A small runner should feel disposable. Try the idea, keep the useful lesson, and leave the accidental environment behind when the next step needs real project context.
How the sandbox answers
- Start with the smallest SQL snippet that can show the behavior.
- Add input only when the program reads it. Empty STDIN is a valid test case.
- Press Run, inspect stdout and stderr, then change one line. That rhythm keeps accidental fixes from hiding the real bug.
The page keeps the run path short. We keep the run cycle compact because this page is meant to answer one question at a time, not manage a full project tree.
That style also makes the result easier to share. A reader can scan a short SQL snippet, run it, and see the same error without first recreating your directory structure or guessing which dependency you forgot to mention.
Keep the example tiny
The saved example below is intentionally left unchanged. Run it once as written, then make a small edit and run it again; that gives you a known-good baseline before you test your own idea.
CREATE TABLE products (
id INTEGER PRIMARY KEY,
name TEXT NOT NULL,
category TEXT,
price REAL
);
INSERT INTO products (name, category, price) VALUES
('Laptop', 'Electronics', 999.99),
('Headphones', 'Electronics', 79.50),
('Desk Chair', 'Furniture', 249.00),
('Notebook', 'Office', 4.99),
('Monitor', 'Electronics', 349.00);
SELECT category, COUNT(*) as count, ROUND(AVG(price), 2) as avg_price
FROM products
GROUP BY category
ORDER BY avg_price DESC;The next preserved block belongs to the same example. Keep it nearby when you are comparing input, output, or the shape of the result. Small examples expose mistakes quickly.
Result 1 (3 rows)
| category | count | avg_price |
|-------------|-------|-----------|
| Electronics | 3 | 476.16 |
| Furniture | 1 | 249.00 |
| Office | 1 | 4.99 |After the sample works, try one edge case that exercises the page's limits. ANSI SQL is the shared center, but every database adds dialect details around dates, strings, limits, and type conversion. That single change often teaches more than pasting a large program and trying to guess which part failed.
Where people use it
Use it when you are stuck on someone else's machine, teaching a small concept, or separating a language question from a project question. No ceremony.
It also works well as a note-taking tool: paste the final snippet into your lesson, issue, or commit message after you have proved it in the runner.
Keep the example slightly smaller than feels natural. That sounds fussy, but it prevents a common debugging mistake: changing five pieces of code, getting a different result, and no longer knowing which piece mattered.
Common questions
These answers focus on the runner's boundaries and the language details most likely to trip up a small SQL example.
What SQL engine does this compiler use?
This page is a lightweight SQL playground, so use it for common SQL ideas rather than engine-specific promises. SELECT, WHERE, JOIN, GROUP BY, and ORDER BY are the right fit. If a feature depends on PostgreSQL, MySQL, SQL Server, or Oracle behavior, check that database directly. A three-row table is usually enough to expose a bad join, alias, or filter.
Is the database persistent?
Assume the database is temporary. If you need the same data later, save the CREATE TABLE and INSERT statements in your own notes. A small seed script is often better than relying on page state, because you can rebuild the exact example whenever you return. When sharing, include the setup data too, otherwise the next person may not see the same result.
Can I use CREATE TABLE?
Yes, CREATE TABLE is the right way to set up a small SQL example. Keep the schema tiny at first: an id column, a name column, and maybe one category or date column. Insert three or four rows, run SELECT *, then add filters or joins after the base table works. A three-row table is usually enough to expose a bad join, alias, or filter.
Do JOINs work?
Yes, JOINs are one of the best things to practice here. Start with two tables that share an obvious key, such as employees.dept_id and departments.id. Run an INNER JOIN first, then try LEFT JOIN so you can see how unmatched rows behave. Once the tiny query is correct, add the larger schema details back slowly. A three-row table is usually enough to expose a bad join, alias, or filter.
Can I use stored procedures?
Stored procedures are database-specific, so they may not work in a general online SQL playground. MySQL, PostgreSQL, SQL Server, and Oracle all use different syntax and runtime rules. Practice plain queries here, then test procedures on the exact database engine you plan to use. A three-row table is usually enough to expose a bad join, alias, or filter. Once the tiny query is correct, add the larger schema details back slowly.
How to run Sql code online?
Write SQL in the editor - CREATE TABLE, INSERT, SELECT, JOIN, GROUP BY, and most standard SQL syntax. The page runs your queries against an in-browser SQLite engine. Click Run and the result rows appear in the output. State persists during your session, so you can build a schema and query it across runs.
Source material
Reference pages are better than folklore when an error message gets specific. Start with official docs, then use tutorials for context once the rule is clear.