How to Practice SQL Online With Nothing Installed

1. Run your first query, right now

Before the explanation: what do you think has to exist on your computer for a SELECT statement to return rows?

The honest answer is nothing at all, and that surprises people who have spent a weekend fighting an installer. A database engine can be compiled to run inside a web page, so the browser tab you already have open is enough to hold a working database, execute real SQL against it, and hand you real rows back.

Open the SQL Drill in another tab and type this:

SELECT * FROM gem_page LIMIT 5;

Rows come back: tracks, listener counts and play counts from a real music dataset. No install, no account, no server. That query is the smallest complete thing SQL can do: name the columns you want, name the table, limit how many rows come back. Everything else you will learn is a refinement of those three decisions.

2. The five tools, and what each is for

They look interchangeable and are not. The useful question is what each one already has loaded, because that decides whether you spend your evening writing queries or writing CREATE TABLE statements.

Two of those solve a problem worth naming. When you ask a SQL question anywhere online, the first reply is usually a request for a runnable example, because nobody can debug a query without the tables. A DB Fiddle link containing your schema and your query is that example, and providing one is the difference between a question that gets answered and one that does not.

3. Where your data goes, and the rule that follows

Before the explanation: you paste a table from a work spreadsheet into an online SQL tool to test a query. Who can now read that table?

It depends entirely on which kind of tool you opened, and the page rarely tells you. Some of these run the database engine inside your browser, so your rows never travel anywhere. Others send your schema and query to their server, run it there, and send results back, which means a copy of everything you pasted now exists on somebody else's machine.

The tools themselves are clear about this when you read far enough. SQLite Online's own disclaimer states that the service is not intended for processing personal data and that the user assumes all risk and liability for uploaded content. DB Fiddle saves fiddles publicly unless you pay for the private option, which is a reasonable business model and a serious hazard if you assumed a saved link was yours alone.

So the rule is short and it has no exceptions worth arguing about. Never paste real customer, patient, employee or financial data into an online SQL tool. Not to test a query, not with the names removed, not for two minutes. Anonymising a table properly is harder than it looks, and a table of "anonymous" hospital admissions with dates and postcodes in it is frequently not anonymous at all.

The practical workaround costs thirty seconds. Retype five made-up rows with the same column names and types as your real table, and test the query against those. The query does not care whether the names are real, and a bug in your JOIN will show up on five rows exactly as it would on five million. When you need to work on the real thing, work locally, which is what setting up a SQL database is for.

4. Which SQL dialect you are learning

SQL is a standard that every database interprets slightly differently. The differences are small in the parts you are learning first and become real later, particularly around dates and text functions.

Most browser tools run SQLite, because it is small enough to compile into a web page. DB Fiddle is the exception worth knowing about, since it lets you choose the engine and version, and it opened on MySQL when I checked it. That matters when you are preparing for a specific job: if the posting says PostgreSQL, practising date functions in SQLite will teach you the wrong syntax for the interview.

Do not let this worry you at the start. SELECT, WHERE, GROUP BY, JOIN, HAVING and window functions behave the same way across all of them, and that is the material of your first several months. The places to expect differences are date arithmetic, string concatenation, and the exact spelling of "give me the top ten". When you meet one, the fix is to search the function name plus your engine's name, not to conclude you have misunderstood SQL.

5. What a browser tab cannot teach you

These tools are excellent at the part they cover, and it is worth being clear about where the ceiling sits, so you know when to move.

They cannot teach you to load data, which is a real skill with real failure modes: a CSV whose numbers arrive as text, leading zeros stripped from postcodes, a date format that means one thing in the UK and another in the US. They cannot teach you performance, because the toy tables are too small for an index to matter. They cannot teach you to connect a tool to a database, which is what every job actually asks for. And nothing you build in most of them survives closing the tab, so there is no such thing as returning to yesterday's work.

Say what that list has in common before reading on. Every item is about the world around the query rather than the query itself. That is the honest boundary: a browser tab teaches you SQL, and a local install teaches you the job. Start in the tab today, and move when the tab starts refusing to hold your work, which usually takes a few weeks.

What goes wrong, and the fix

Six that come up constantly.

"no such table". Table names differ between tools, and tutorials are written against whichever one the author used. Read the schema panel on the left rather than the tutorial. On sql-practice.com the tables are patients, admissions, doctors and province_names.

Your work vanished when you closed the tab. Most of these keep nothing. Paste anything you want to keep into a text file on your own machine as you go. A file of queries that worked becomes the thing you paste from later.

A date function that works everywhere else fails here. Dialect. DATEADD, DATE_ADD and date(...,'+1 day') are three engines' spellings of one idea. Check which engine the tool is running before you conclude the query is wrong.

The query runs but returns nothing. Usually a WHERE comparing against a value that does not exist, often because of capitalisation or a trailing space. Take the WHERE clause off and look at the raw values first.

You expected an error and got a wrong answer instead. SQLite is unusually permissive about types, so comparing a number to text can quietly yield nothing rather than complaining. That flexibility is convenient and it hides mistakes, which is one more reason to move to a real engine eventually.

A shared fiddle is public. Saved fiddles are visible unless privacy is a paid feature you have paid for. Assume anything you save can be read.