SQL Runner Guide: Test SQLite Queries in Your Browser

Sometimes you need to answer a small SQL question without connecting to a real database: does this join duplicate rows, will a window function produce the intended rank, or does a constraint reject bad data? The ByteKiln SQL Runner creates a temporary SQLite database in your browser so you can run a schema and test queries in isolation.

Nothing is installed and the database disappears when the page is reloaded. That makes it useful for experiments, examples, and debugging—not for storing important data.

Set up the smallest useful schema

Start with only the tables and rows needed to demonstrate the behavior. For example:

CREATE TABLE customers (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL
);

CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  customer_id INTEGER NOT NULL,
  total_cents INTEGER NOT NULL,
  created_at TEXT NOT NULL,
  FOREIGN KEY (customer_id) REFERENCES customers(id)
);

INSERT INTO customers (id, name) VALUES
  (1, 'Asha'),
  (2, 'Bilal');

INSERT INTO orders (customer_id, total_cents, created_at) VALUES
  (1, 2500, '2026-09-01'),
  (1, 4000, '2026-09-05'),
  (2, 1800, '2026-09-03');

Run the schema first. The tool reports table information so you can confirm that setup succeeded before debugging a query.

Test the query and its edge cases

A total-per-customer query might be:

SELECT
  c.id,
  c.name,
  COUNT(o.id) AS order_count,
  COALESCE(SUM(o.total_cents), 0) AS total_cents
FROM customers AS c
LEFT JOIN orders AS o ON o.customer_id = c.id
GROUP BY c.id, c.name
ORDER BY total_cents DESC;

Add a third customer with no orders. That one fixture verifies why LEFT JOIN and COALESCE are present. Good SQL tests include empty relationships, duplicate-looking values, NULL, ties, and boundary dates—not only the happy path.

The results grid shows every returned result set, while execution timing gives a rough local measurement. Timing in a small browser database is not a production benchmark; it is mainly useful for catching obviously expensive experiments.

Use transactions for destructive experiments

When testing updates or deletes, wrap the statements in a transaction:

BEGIN;

UPDATE orders
SET total_cents = total_cents + 500
WHERE customer_id = 1;

SELECT * FROM orders WHERE customer_id = 1;

ROLLBACK;

SQLite supports transactions, constraints, indexes, common table expressions, and window functions, so many data-shaping ideas can be tested accurately. Reloading or rerunning the schema also gives you a clean database.

Know where SQLite differs

The runner uses SQLite compiled to WebAssembly. A query that works here is not automatically portable to PostgreSQL, MySQL, SQL Server, or Oracle. Important differences include:

• date and time functions;
• JSON operators and types;
• automatic type conversion;
• identifier quoting;
• generated columns and identity syntax;
• ALTER TABLE capabilities;
• procedural SQL and stored routines;
• query planners and index behavior.

Use the runner to validate relational logic, then test the final statement against the same database engine and version used in production. Never treat browser timing as evidence that a query will scale against millions of rows.

Format before reviewing

Complex queries are easier to reason about when clauses and joins are visually separated. The SQL Formatter can normalize indentation before you paste the query into the runner or a pull request. If you are starting from sample JSON, the JSON to SQL converter can produce an initial schema, but review its data types, keys, constraints, and indexes before running it.

A reliable workflow

1. Reduce the production problem to a small schema.
2. Add fixtures for both normal and awkward cases.
3. Run the schema and inspect the detected tables.
4. Execute one query at a time and verify exact rows.
5. Add constraints and indexes that are part of the intended design.
6. Move the tested query into an automated integration test for your real database.
7. Review the real query plan before shipping performance-sensitive SQL.

An in-browser runner is strongest as a scratchpad. The lasting value comes from turning the successful experiment into a repeatable database test in the application repository.