SQL Query Builder
Build SQL queries visually for testing and development.
100% private100% private
Compose SELECT, INSERT, UPDATE, and DELETE statements by filling in the table, columns, conditions, and values in a structured form. The generated SQL uses standard syntax compatible with MySQL, PostgreSQL, and SQLite. Useful for sanity-checking a query before running it against production, teaching SQL to newcomers, or scaffolding the boring parts of a CRUD endpoint. The query is composed in your browser — schema names you type are not logged.
Next steps
JSON Formatter
RecommendedInstantly format, validate, or minify JSON — spot errors in seconds.
Code Formatter
RecommendedMake messy code readable — beautify or minify JS, HTML, CSS, YAML, and SQL.
cURL to Code
Convert cURL commands to JavaScript fetch, Axios, Python, or PHP code.
Regex Tester
Write and test regex patterns with real-time match highlighting.
Runs right inside your browser tab. 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
01
Learning SQL syntax
Build queries visually and study the assembled output to understand clause order and keyword spelling.
02
Generating CRUD scaffolds
Produce skeleton SELECT, INSERT, UPDATE, and DELETE statements for new tables during prototyping.
03
Quick admin queries
Compose ad-hoc queries against logging or staging databases without firing up a full SQL IDE.
04
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.