Developer Tools / SQL
SQL Copilot
Correct SQL first, fast SQL second.
A dialect-aware SQL assistant with focused workflows for writing, debugging, translating, testing, and tuning queries. It works from the schema, errors, and plans you share, and checks grain, joins, and NULLs before performance.
01 — The product
What is SQL Copilot?
SQL Copilot turns plain-language requirements into SQL and explains, debugs, and translates existing queries between dialects. It reviews risky writes and schema migrations, designs BI, CDC, and reconciliation logic, and writes test fixtures with expected results.
It’s built for analysts, BI teams, data engineers, platform teams, and application developers. It suits people who work across more than one database engine and can’t afford syntax from the wrong dialect.
Before writing anything, it settles what one output row represents, how each join can multiply rows, and how NULLs and time boundaries behave. It won’t hide duplicates with DISTINCT, optimize a query that is still wrong, or call SQL tested without real output.
02 — Real workflow
A duplicate-contact cleanup needs a DELETE
The problem
A team wants to remove duplicate customer contacts in PostgreSQL and already has a DELETE written. Nobody has checked how many rows it touches or which row survives.
DELETE FROM customer_contacts c
USING customer_contacts d
WHERE c.email = d.email
AND c.contact_id < d.contact_id;How SQL Copilot approaches it
- 1Classifies the statement as high risk and states exactly which rows it can remove and whether the change can be reversed.
- 2Tests the duplicate key against case and whitespace in email, NULL emails, and whether the lowest contact_id is really the row to drop. Then it defines a winner and a deterministic tie-breaker.
- 3Writes a read-only preview that uses the same predicates, with affected-row counts, distinct-key counts, and checks for rows matched more than once.
- 4Puts the DELETE in a separate block under an explicit warning, to run only after the preview is validated. It wraps the statement in a transaction and adds backup or restore guidance that fits PostgreSQL.
Expected result
You get a preview query, validation checks, and a guarded DELETE, with its assumptions stated. You run each step and judge the results yourself.
Illustrative workflow. It doesn’t depict a real session, system, or result.
03 — Areas of expertise
Where it helps
Dialect translation
Translates between engines, including PostgreSQL, SQL Server, Oracle, Snowflake, BigQuery, Redshift, and Databricks SQL. Flags features without equivalents and silent changes like Oracle empty strings or integer division.
Plan-based tuning
Reads execution plans and query profiles for pruning, spill, shuffles, and scans. It doesn’t promise gains from CTEs, indexes, clustering, or bigger compute without evidence.
Schema migration review
Plans expand, migrate, and contract steps for breaking changes and checks locks, table rewrites, and backfill cost. It won’t call DDL transactional everywhere or zero-downtime without evidence.
SQL security and access
Parameterizes user input, allowlists dynamic identifiers, and reviews least privilege, row and column policies, masking, and GRANT or REVOKE changes. It never bypasses access controls.
04 — Working with SQL Copilot
What to provide and what to expect
Share
- The target platform and version, plus the source platform for translations
- Table definitions, keys, and a few sample rows
- The query, the error message, or a plain-language requirement
- Execution plans or query profiles for slow queries
- The intended scope of any data or schema change
Expect
- One copyable query with only the assumptions that matter
- A short explanation of joins, filters, NULL handling, and output grain
- Validation queries and test fixtures with expected results
- Preview-first scripts for UPDATE, DELETE, MERGE, and schema changes
It doesn’t connect to databases or run SQL on its own. It works from the schema, rows, and plans you share, and won’t call a query tested or tuned without real output.