Skip to content
QueryLab

SQL practice that looks like the job

QueryLab is a set of business questions, not a tour of syntax in isolation. Each exercise gives you a schema, a reason the question exists, and a result you can check.

What to practice first

Start with filters and sorting until a WHERE clause feels automatic. Then join two tables, aggregate, and only after that reach for windows. Interviews rarely fail on SELECT *. They fail when a join duplicates revenue or a filter treats NULL as zero.

How QueryLab checks your work

Your query runs in SQLite inside the browser. QueryLab compares column names, row count, values, and order. A message such as a mismatched row count is the hint. The reference SQL stays on the server until you choose to reveal it.

Example

SELECT country, COUNT(*) AS customers
FROM customers
GROUP BY country
ORDER BY customers DESC, country;

Count people after you decide the grain. Here the grain is one row per country.

Practice

Common mistakes

  • Joining line items before counting customers, which counts purchases instead of people.
  • Sorting by a column you did not group or aggregate.
  • Using a limit to mean 'the latest' without an ORDER BY.
  • Comparing a nullable column with = NULL.

FAQ

Do I need an account to practice?
No. You can solve exercises immediately. An account saves the streak, drafts, and completed set across browsers.
Which SQL dialect is this?
The sandbox is SQLite. The core of SELECT, JOIN, GROUP BY, and window functions matches what you will write for MySQL and PostgreSQL. Date functions and a few string operators differ, and the dialect pages call those out.
Are the queries executed on a server?
No. Each run builds a fresh SQLite database in your browser from the exercise seed. The application database only stores accounts and progress.

Related practice

Start solving SQL challenges today.

Open Customers in Germany and check the result in the browser. An account is optional.

Start practicing free