Putting the database tool right next to the data, instead of installing it on every engineer's laptop — that's the most visible design posture of the 0.15 release of open-source SQL IDE LibreDB Studio. The MIT-licensed project published this update on September 8 and turned "LLM Agent as a first-class SQL citizen" into something usable in production.

Sixteen engines, one browser entry

LibreDB Studio deploys as a container, a Helm Chart, or an OpenShift Operator; it also starts on a server with npx @libredb/studio. The browser, a phone, and Windows / macOS / Linux desktops open the same interface. It covers sixteen database engines (PostgreSQL, MySQL, Oracle, SQL Server, SQLite, libSQL, DuckDB, MongoDB, Redis, Couchbase, ClickHouse, Apache Druid, Elasticsearch, OpenSearch, Apache Trino, Apache Cassandra), all sharing one schema browser, ER diagrams, schema diff, and monitoring panel. The PostgreSQL project, Redis, ClickHouse, Trino, and Apache Cloudberry all list it as recommended in their official docs — an unusual credibility signal for an open-source tool.

The Agent runs on an audited, read-only pipeline

Version 0.15 upgrades AI from "an explain button next to the query" to "an Agent panel beside the editor." The user writes down a goal — "which department has the most employees?" "Why is this query slow?" — presses Start, and the Agent drafts SQL, reads the results, and finally writes a report whose every claim cites the source row it came from.

But this Agent does not block danger by parsing SQL; it hands read-only enforcement back to the database itself. PostgreSQL uses a read-only transaction. SQLite re-asserts PRAGMA query_only before every statement. DuckDB uses a READ_ONLY engine handle plus an SQL-level guard. All writes and DDL are rejected before they reach the driver. EXPLAIN ANALYZE is denied by default because it would actually run the statement. This audited pipeline belongs to the Agent alone — SQL the user runs directly in the editor does not go through it, and produces no audit event.

Supported models are spelled out clearly: Gemini 2.5 Flash is the default; OpenAI, Ollama, or any OpenAI-compatible endpoint is supported the same way. Agent mode requires tool-calling capability, and the README warns that on Ollama, a live probe — not the vendor page — is what establishes that.

The read-only profile only exists on three databases

The read-only execution profile is database-native, so it exists only where a provider implements it — PostgreSQL, SQLite, and DuckDB. On the other thirteen engines, Agent mode runs end with engine-unsupported.

Plan mode is the fallback: it uses no tools, accesses no data, and only translates a goal into a SQL draft for the user to run themselves; its schema grounding works on all sixteen engines. Every Agent run has explicit caps: at most 20 statements, 60 seconds of database time, 200 rows per read, a 5-minute deadline for the whole run.

Where the boundary sits

Plugging an LLM Agent into an open-source SQL tool isn't new. But this line has a few choices worth noting: "the tool goes to the data" and "the user uses the tool themselves" are two distinct paths; the Agent-mode boundary is expressed in terms of native database capabilities, rather than the project writing its own SQL parser — the latter tends to leak in production; the license is MIT rather than a stricter source-available license, because "you cannot place a per-seat licensed, feature-gated tool into every environment you own" — a position the project writes out plainly in the README. For teams that need to run a database tool on their own servers and keep data from leaving via a local LLM, this is an option worth evaluating, on the condition that Agent mode is only available on three databases and the rest are handed to Plan mode.