Which databases are supported?

MySQL, PostgreSQL, and SQLite. The generated SQL uses standard syntax compatible with all three.

Can I build JOIN queries?

Yes — configure INNER JOIN, LEFT JOIN, and RIGHT JOIN with table aliases.

Can I use aggregate functions?

Yes — COUNT, SUM, AVG, MIN, MAX are all available with GROUP BY and HAVING support.

Is the SQL validated?

Syntax is generated from your inputs and will be valid as long as your table/column names are correct.

What's the difference between WHERE and HAVING?

WHERE filters rows before grouping — it operates on individual row values. HAVING filters after GROUP BY — it operates on aggregated values like COUNT(*) > 10. You can use both in the same query.

Should I use SELECT * in production?

Avoid it. SELECT * fetches all columns, including ones your application doesn't need, increasing network transfer and memory usage. Always name the columns you need explicitly — it also makes queries self-documenting.

SQL Query Builder

Build SQL queries visually for testing and development.

Query Builder

Configure your SQL query

Query Type

Table Name

Columns (comma-separated, or * for all)

WHERE Condition (optional)

Examples

SELECT:

SELECT * FROM users WHERE age > 18;

INSERT:

INSERT INTO users (name, email) VALUES (?);

UPDATE:

UPDATE users SET name='John' WHERE id = 1;

Next steps

JSON Formatter

Recommended

Instantly format, validate, or minify JSON — spot errors in seconds.

Code Formatter

Recommended

Make messy code readable — beautify or minify JS, HTML, and CSS.

cURL to Code

Convert cURL commands to JavaScript fetch, Python, or PHP code.

Regex Tester

Write and test regex patterns with real-time match highlighting.

View all tools →

Runs entirely in your browser. No uploads. Your files stay private.

How to Build SQL Queries Visually

SQL (Structured Query Language, ISO/IEC 9075) is the lingua franca of relational databases. Despite vendor-specific extensions, the core grammar — SELECT, INSERT, UPDATE, DELETE, plus the clauses WHERE, JOIN, GROUP BY, HAVING, ORDER BY, and LIMIT — is shared across PostgreSQL, MySQL, MariaDB, SQLite, SQL Server, and Oracle. This builder targets that common subset so the output is portable across the engines you are most likely to use.

The tool is intentionally a string assembler, not a parser. It reads the table name, comma-separated columns, optional WHERE condition, and selected query type, then concatenates them with the appropriate keywords. There is no AST, so the output is exactly what you typed plus the SQL keywords — useful for learning and prototyping, but the responsibility for valid identifiers and quoting rests with you.

Crucial security point: the INSERT template emits VALUES (?) as a parameter placeholder rather than substituting your input directly. That is intentional — anything constructed by string concatenation that includes user-controlled data is a SQL injection risk. In production, parameterize values via your driver (psycopg, mysql2, sqlite3, JDBC, ADO.NET, ORM bindings) so the database receives data as parameters, not as code. The output of this tool is meant to be the skeleton; binding values is your job.

Identifier quoting differs by engine. PostgreSQL and SQLite use double quotes ("users"), MySQL backticks by default (`users`), and SQL Server square brackets ([users]). The output here is unquoted, so if your column or table name contains spaces, reserved words, or mixed case, wrap it in the correct quoting style before running. Reserved words like USER, ORDER, and TIMESTAMP are common gotchas.

Logical execution order is not the same as written order. SQL evaluates FROM first (which establishes the row source), then WHERE (filtering rows), GROUP BY (forming groups), HAVING (filtering groups), SELECT (projecting columns), DISTINCT, ORDER BY, and finally LIMIT/OFFSET. Knowing this order explains why you cannot reference a column alias defined in SELECT inside the WHERE clause but you can in ORDER BY — at WHERE time the alias does not exist yet.

Performance matters more than syntax in real-world queries. Avoid SELECT * because it pulls every column over the wire and prevents index-only scans. Filter early with selective WHERE predicates that use indexed columns. Add covering indexes for the (filter, sort, project) shape your common queries take. Use EXPLAIN (or EXPLAIN ANALYZE in PostgreSQL) to verify the planner is using your indexes and not falling back to sequential scans.

All query construction happens in your browser via plain string concatenation in a React state hook. Nothing is sent to a server, no SQL is executed against a database, and no schema introspection is performed. Closing the tab discards the inputs.

Common Use Cases

Learning SQL syntax

Build queries visually and study the assembled output to understand clause order and keyword spelling.

Generating CRUD scaffolds

Produce skeleton SELECT, INSERT, UPDATE, and DELETE statements for new tables during prototyping.

Quick admin queries

Compose ad-hoc queries against logging or staging databases without firing up a full SQL IDE.

Onboarding documentation

Generate example queries for runbooks and onboarding guides that show new engineers the table layout.

Frequently Asked Questions

The output uses the SQL-92 / SQL-99 common core, which runs on PostgreSQL, MySQL, MariaDB, SQLite, SQL Server, and Oracle. Vendor-specific syntax (RETURNING, ILIKE, ON CONFLICT, MERGE) is not generated here — add it manually when you need it.

Wrap them in the engine's quoting characters: double quotes for Postgres and SQLite, backticks for MySQL, and square brackets for SQL Server. The tool emits identifiers unquoted, so add quoting when you paste the query.

Because user-supplied values must be parameter-bound rather than concatenated into SQL — that is the only safe defense against SQL injection. The ? is a placeholder; your application driver substitutes the actual value at execution time.

Not visually — this builder targets single-table CRUD. To compose JOINs, write the FROM and JOIN clauses by hand in the columns and condition fields, or use a richer query authoring tool like DBeaver, DataGrip, or pgAdmin's query editor.

WHERE filters individual rows before grouping; HAVING filters groups after GROUP BY has formed them. Use WHERE to restrict by raw column values and HAVING for predicates on aggregates like COUNT(*) > 10 or SUM(amount) > 1000.

For ad-hoc exploration in a SQL prompt, sure. For application code, no — explicit column lists make queries faster (less data over the wire), more index-friendly, more refactor-safe (a new column does not silently appear), and self-documenting.

Double it. The literal It's becomes 'It''s' in standard SQL. MySQL and SQLite also accept the backslash form '\' as a fallback, but standard double-quoting works everywhere.

OFFSET-based pagination (LIMIT 20 OFFSET 100) is simple but slow on large tables because the database still walks past 100 rows. Keyset pagination (WHERE id > :last_seen ORDER BY id LIMIT 20) scales much better when you have an indexed sort column.

Common culprits: applying a function to the indexed column (WHERE LOWER(email) = ...) defeats the index unless you have a functional index; using OR across multiple columns; or implicit type coercion (comparing a TEXT column to an integer). Run EXPLAIN to see the plan.

No. The tool concatenates strings in your browser. No queries are executed, no databases are introspected, and no telemetry is collected.