GitHub Copilot for SQL: What Works in Practice

Autocomplete Is a Different Tool

In-editor completion is a genuinely different proposition from a chat assistant. It sees your file, it suggests as you type, and — critically — you review each suggestion at the moment you would otherwise have been typing it. That review timing is most of why it works.

What Works Well

• Repetitive DDL. Write two CREATE TABLE statements in a consistent style and the third is largely typed for you. Excellent at consistency of naming and column ordering.
• Boilerplate around a query. The INSERT column list that matches the table you just defined; the trigger function skeleton.
• Test data. Plausible seed rows, quickly.
• Comment-first drafting. Write the intent as a comment and let it draft the statement. Works because you specified the goal before seeing the answer, which keeps you reviewing rather than accepting.
• Migration file scaffolding. The up/down pair in whatever framework you use.

Where It Quietly Misleads

• Column names it has never seen. It completes from patterns in your file, so it will confidently produce customer_id when your column is cust_no — and the SQL looks perfect until it runs.
• JOIN conditions. It infers the join key from naming convention. When your schema is inconsistent — and a twenty-year-old schema is — it silently guesses wrong and returns a plausible number of rows.
• WHERE clauses on the wrong side of a NULL. Especially post-migration, where Oracle’s empty-string-is-NULL behaviour no longer holds.
• Dialect blending. It will suggest NVL in a PostgreSQL file if your project recently contained Oracle code, and TOP or LIMIT depending on what it saw last.
• DELETE and UPDATE without a WHERE. Rare, but the consequence is unbounded. Never accept a destructive statement from a completion without reading it.

During a Migration Specifically

Migration work is the worst case for completion tooling, for one structural reason: your files contain both dialects at once. Oracle source on one side, PostgreSQL target on the other. The model completes from local context, and the local context is contaminated — so you get Oracle idioms suggested into PL/pgSQL and vice versa, with high confidence and correct-looking syntax.

Keep the two apart. Convert through a deterministic tool rather than by typing with assistance, and use completion for the surrounding work — the test harness, the deployment scripts, the checks — where its context is clean.

The Practice That Makes It Safe

Treat every suggestion as a draft from a colleague who has not seen your schema — because that is exactly what it is. Verify identifiers against the catalog rather than against how right they look. And never let a completion be the last thing that happens before a statement runs against a real database.