Home › AI for DBeaver
SqlSage turns plain-English questions into SQL in the dialect of your active connection — the same chat panel and editor actions across PostgreSQL, MySQL/MariaDB, Oracle, SQL Server and SQLite. Learn one tool once; use it on every relational database DBeaver can open.
Teams rarely live on a single database. You have Postgres in production, a MySQL side service, an Oracle system of record, SQL Server for the reporting stack, a SQLite file on your laptop — and each has its own quirks of syntax. SqlSage collapses that into one assistant with one workflow: ask in plain English, get SQL that fits the connection you are on, run a read, gate a write. The muscle memory is the same everywhere.
There is no per-engine plugin to install and no mode to switch. Change the active connection in DBeaver and the assistant re-targets itself — new schema context, new dialect — on the next message.
Chat, schema context, statement classification, the confirmation gate, connection policies, the kill-switch and the audit log work on every relational connection DBeaver can open. Dialect-aware SQL generation is tuned per family:
| Engine family | Dialect-aware SQL | Typical dialect gotchas SqlSage accounts for |
|---|---|---|
| PostgreSQL | Yes | LIMIT/OFFSET paging, double-quoted identifiers, || concatenation, dollar-quoting. |
| MySQL / MariaDB | Yes | LIMIT paging, backtick identifiers, CONCAT(), executable-comment syntax. |
| Oracle | Yes | FETCH FIRST / ROWNUM, uppercase folding, || concat, DUAL. |
| SQL Server | Yes | TOP / OFFSET…FETCH, bracket identifiers, + concat, T-SQL shapes. |
| SQLite | Yes | LIMIT paging, flexible typing, || concat, a narrower function set. |
DBeaver connects to many more engines than these; SqlSage still chats and classifies on them. What is engine-specific — query plans, table-size and active-session diagnostics, and the dialect hints above — is described in full on the engine-coverage page, including where a plan comes back as a “recipe” rather than a single read.
The reason a generic “text-to-SQL” box disappoints on a real database is that it guesses identifiers and writes for the wrong dialect. SqlSage avoids both. It grounds every query in your live schema — tables, columns, keys and indexes read through metadata tools — so it uses names that exist, and it ships the model per-engine dialect hints so paging, quoting, concatenation and null handling come out right for the connection you are on.
The model inspects the schema before writing SQL and is told never to invent identifiers.
Explain a query, optimize it, or explain the real error text from your last failed run — then get a corrected version.
Right-click → SqlSage in the SQL editor, or chat commands like /explain, /optimize, /fix, /format. Copy or insert the result.
Breadth does not mean a weaker gate on the less-common engines. The classifier chokepoint is engine-agnostic: on every connection, a plain SELECT runs and anything not proven to be a read is held for an explicit confirmation dialog showing the exact SQL. One statement per call: a multi-statement batch is refused, never run. Per-connection Read-only / No execution policies and the global kill-switch apply identically whether you are on SQLite or Oracle, and every decision lands in the same local, hash-chained audit log.
We are equally explicit about the limits — an engine-enforced read-only transaction only on PostgreSQL and MySQL/MariaDB, a query timeout only as reliable as the driver, a client-side row cap. Read them in full on the safety model page before pointing the assistant at production.
You do not wire up a key per database. SqlSage is keyless: it signs in through the Claude (Anthropic) or ChatGPT/Codex (OpenAI) CLI you already have, and that single account serves all five engines. No API key, no per-engine setup, no separate AI bill. The mechanics — how sign-in works, both providers in one panel, and what leaves your machine — are on the companion page: Claude & ChatGPT in DBeaver, on your own account →
Engines, dialects, safety and the audit trail. Sign-in, cost and what leaves your machine are covered in the Claude & ChatGPT in DBeaver FAQ.
The relational engines DBeaver connects to — PostgreSQL, MySQL/MariaDB, Oracle, SQL Server and SQLite. Chat, schema context, classification, the confirmation gate, connection policies, the kill-switch and the audit log work on every relational connection DBeaver can open. A few features (query plans, table-size and active-session diagnostics) are per-engine because they need engine-specific SQL; where an engine has no SQL for one, that tool is simply not offered.
Yes. SqlSage detects the dialect and capabilities from the active connection, not from a hardcoded setting, and ships the model short per-engine dialect hints — paging syntax, identifier quoting and case folding, string concatenation and null handling — so generated SQL matches the engine you are actually connected to.
One plugin, one workflow. You install SqlSage once into DBeaver 26.x and use the same chat panel and editor actions on every connection. Switch the active connection and the assistant follows, re-targeting its schema context and dialect to the new engine automatically.
No. SqlSage is keyless: it signs in through the Claude (Anthropic) or ChatGPT/Codex (OpenAI) CLI you already have, and that one account serves every engine. There is no API key and no per-engine or per-token AI fee from SqlSage — usage counts against your existing Claude or ChatGPT plan.
Yes. A statement runs automatically only when the parser, configured for the connection’s dialect, proves it is a read-only SELECT. Writes, DDL and anything the parser cannot make sense of never run automatically: they stop in a confirmation dialog that names the target connection, shows every statement in full and makes Cancel the default. Multi-statement input is refused outright. On top of that, a connection can be set to Read-only (writes hard-refused) or No execution, and a global kill-switch freezes every AI-initiated statement. The limits — including that an engine-enforced read-only transaction exists only on PostgreSQL and MySQL/MariaDB — are on the safety model page.
A generic chat sees only what you paste, so it guesses identifiers and often writes for the wrong dialect. SqlSage works on your live connection: the model calls metadata tools such as list_tables and get_schema (columns, types, primary and foreign keys, indexes), is instructed to inspect the schema before writing SQL and never to guess identifiers, and gets per-engine dialect hints. It can also run a cleared read itself — on SqlSage’s own connection, never inside your editor’s transaction — and return the rows. The model never gets a database handle, only a fixed, vetted tool set behind the safety gate.
Yes. Every classification decision and every executed statement is appended to a local, hash-chained JSONL file (%LOCALAPPDATA%\SqlSage\audit\), on by default and never uploaded. Writes the assistant proposes are logged at every stage even if you switch audit logging off. Each record carries the first line of the statement, never result data, and the hash algorithm is published so you can verify the chain yourself — see the audit log reference.