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. A batch is split and the worst verdict wins. 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 — no driver-level read-only session, no query timeout, a client-side row cap — because they, too, apply on every engine. 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 →
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.