# LibreDB Studio — full reference for LLMs > LibreDB Studio is the open-source database IDE that deploys next to your data instead of onto your laptop — one browser tab for PostgreSQL, MySQL, MongoDB, Redis and fifteen more engines, with SSO and audit built in. - Website: https://libredb.org - Source: https://github.com/libredb/libredb-studio - Live demo: https://app.libredb.org - Documentation: https://github.com/libredb/libredb-studio/tree/main/docs - Licence: MIT - Current version: 0.17.0 ## Vendor LibreDB is a product brand. The company that develops, publishes and supports it is a limited liability company registered in Turkiye. These details are matters of public record and can be verified independently. - Registered company name: Sekoya Grup Bilisim ve Teknoloji Ltd. Sti. - Trade name: Sekoya Tech - Registered office: Inkilap Mah. Hasim Iscan Sok. Kent Sitesi F Blok No: 4/33, 34768 Umraniye / Istanbul, Turkiye - Tax office: Umraniye - Tax ID (VKN): 7591146987 - MERSIS No: 0759114698700001 - Trade Registry No: 1015843 - Company website: https://sekoya.tech - Contact: info@sekoya.tech Vendor support, with the supported Kubernetes and runtime versions, is stated at https://libredb.org/support. ## What it is LibreDB Studio is a database IDE that is deployed next to the data rather than installed on a laptop. It runs as one container inside the same network as the database, so the database needs no public exposure, no per-person tunnel and no credential copied onto each machine. Access is granted and revoked through an OIDC identity provider. The comparison that matters is not a feature list but where the tool runs; that argument is at https://libredb.org/compare. ## Supported engines (19) | Engine | Category | Transport | |---|---|---| | PostgreSQL | SQL | pg pool · 5432 | | MySQL | SQL | mysql2 pool · 3306 | | Oracle | SQL | oracledb pool · 1521 | | SQL Server | SQL | mssql pool · 1433 | | SQLite | SQL | file · embedded | | libSQL | SQL | hrana · 443 | | DuckDB | Analytics | file · embedded | | ClickHouse | Analytics | http · 8123 | | Apache Druid | Analytics | http · 8888 | | Trino | Federated | http · 8080 | | MongoDB | Document | driver · 27017 | | Couchbase | Document | http · 8091 | | Redis | Key-value | resp · 6379 | | LibreDB | Key-value | file · embedded | | Cassandra | Wide-column | cql · 9042 | | Elasticsearch | Search | http · 9200 | | OpenSearch | Search | http · 9200 | | Prometheus | Time-series | http · 9090 | | Apache Kafka | Streaming | kafka · 9092 | ### What each engine does NOT do These boundaries are documented rather than omitted. Agent mode, for example, is available on three engines and not on the rest. - **PostgreSQL** — Nothing held back — every capability in the product ships here, including agent mode. - **MySQL** — Agent mode is unavailable, as on every engine but PostgreSQL, SQLite and DuckDB. - **Oracle** — Agent mode is unavailable here. Operate still reads the server's own reporting interface. - **SQL Server** — Agent mode is unavailable here; the editor, diagrams and health are identical. - **SQLite** — There is no server to monitor: health reads file size and pragma statistics only. - **libSQL** — Monitoring is limited to what the sqld server itself exposes. - **DuckDB** — Single-writer by design: no sessions to list, so health shows storage, not connections. - **ClickHouse** — No foreign keys exist, so ER diagrams show structure without discovered relations. - **Apache Druid** — Append-oriented: row editing is disabled rather than offered and then failed. - **Trino** — Trino queries catalogs; it does not manage a lakehouse. Writes depend on the underlying connector. - **MongoDB** — No SQL translation layer is faked — queries here are MongoDB queries. - **Couchbase** — Agent mode is unavailable, as on every engine but PostgreSQL, SQLite and DuckDB. - **Redis** — No SQL, and none is pretended — the editor speaks commands here. - **LibreDB** — No sessions and no index objects exist, so those two panels are absent with their reason rather than answered empty. Maintenance operations are refused, not faked. - **Cassandra** — No joins and no EXPLAIN — the grid respects partition-key query rules instead of hiding them. - **Elasticsearch** — Search engines are query-and-browse: no row editing, no ER diagrams. - **OpenSearch** — Search engines are query-and-browse: no row editing, no ER diagrams. - **Prometheus** — Read-only: Studio calls the read APIs only, so there is nothing to write back. - **Apache Kafka** — Read-only: it reads records, it does not produce them. ## Features ### Schema-aware SQL editor The editor is Monaco — the same core VS Code runs on — wired to the connected database rather than to a file on disk. Completion is drawn from the live catalog, so it offers your tables and your columns, not a generic SQL keyword list. - Schema-aware completion for tables, columns and keywords - Multi-tab workspace, each tab with its own execution state - Formatting and snippets; ⌘⏎ / Ctrl+⏎ runs the statement - Schema diff across snapshots or two connections, with migration SQL generated - A snapshot timeline — pick any two points and compare **Limit:** Migration SQL is generated for PostgreSQL, MySQL, SQLite, Oracle and SQL Server, plus ClickHouse column modifications. Other engines diff but do not emit migrations. ### Visual EXPLAIN Plans come back from the engine and are drawn as a tree rather than printed as text: scan types, join strategies and costs laid out so the expensive node is the one you see first. - Graphical execution plans, node by node - Scan type, join strategy and cost surfaced per node - Reads each engine’s own plan output — nothing is simulated **Limit:** Plan rendering follows the engine: PostgreSQL, MySQL, DuckDB, ClickHouse and Trino among others expose a plan this can draw. Where an engine has no plan interface, there is nothing to render. ### ER diagrams The diagram is discovered, not drawn by hand: foreign keys are read from the schema and laid out hierarchically by ELK.js, so the graph reflects what the database actually declares. - Real foreign-key edges with cardinality labels - MiniMap navigation, table search and filter, compact mode - Automatic hierarchical layout (ELK.js) - Export as PNG or SVG **Limit:** Edges come from declared foreign keys. A relationship your application enforces in code but never declares in the schema has nothing to discover, and will not appear. ### AI that knows your schema The model-backed helpers sit beside the editor: explain a plan in plain language, draft a statement from a description, get a risk read before a destructive statement runs. The connected schema goes with the request, so the answer names your tables. - Query explainer — EXPLAIN output translated, with suggestions - Pre-execution risk analysis for DELETE, DROP and TRUNCATE - Data profiler summaries written up in prose - Gemini (default), OpenAI, Ollama, or any OpenAI-compatible endpoint - Generated SQL is yours to read; nothing runs itself **Limit:** With no LLM settings configured at all, the rail does not render and nothing leaves your network. Note that an API key is not the switch — Ollama and a custom endpoint count as a configured model without one. ### Live health dashboard A monitoring surface read from each engine’s own reporting interface — seven tabs covering overview, performance, queries, sessions, tables, storage and the connection pool, refreshed on an interval you choose. - Time-series trends for connections, cache hit ratio, buffer pool and deadlocks - Auto-refresh from 5s to 60s, with play/pause - Colour-coded health thresholds — healthy, warning, critical - Live pool metrics: total, active, idle, waiting - One-click VACUUM, ANALYZE, REINDEX, UPDATE STATISTICS, DBCC CHECKDB, ALTER INDEX REBUILD - An audit trail of every query executed across the organisation **Limit:** The maintenance toolkit and the audit trail are admin-only. What each panel can show is bounded by what the engine reports — an embedded engine with no sessions shows storage, not connections. ### The database agent You state an objective and press Start. The run drafts SQL, reads what comes back, and composes a report in which every claim cites the result it came from. It never starts itself, never writes to the editor, and never executes what it recommends. - Three workflows — Investigate, Optimize, Assess - Read-only enforced by the database, not by a parser: a read-only transaction on PostgreSQL, PRAGMA query_only re-asserted per statement on SQLite, a READ_ONLY handle plus an SQL guard on DuckDB - Every statement passes a policy decision, an audit event and budget accounting before the driver is touched - Bounded and metered on screen: 20 statements, 60s of database time, 200 rows per read, a 5-minute deadline - Evidence or nothing — a claim with no citation cannot be composed - The run states its own verdict: “Run answered” or “Run did not answer” **Limit:** Agent mode reads PostgreSQL, SQLite and DuckDB only, because the read-only profile is database-native and exists only where a provider implements it. On any other engine a run ends engine-unsupported. Plan mode opens on every connection — it is toolless, runs nothing, and drafts a statement for you to run yourself. The embedded @libredb/studio package carries no agent surface at all. ## Security What is enforced and where, plus the documented limits it stops at, is at https://libredb.org/security. The limits are published deliberately: credentials are held unencrypted in browser localStorage unless a server-side store is configured, the built-in local login compares passwords without hashing, masking is a display-level control, and rate limits are counted per replica. The security policy is at https://github.com/libredb/libredb-studio/blob/main/SECURITY.md. ## Deployment (26 live channels) - **GitHub Releases** Standalone tarballs plus the .deb, .rpm and snap assets every other channel repackages. - **npm — @libredb/studio** — `npx @libredb/studio` No Docker needed. Node 24+; downloads the release server archive. Also the package you embed in your own product. - **Docker image — GHCR** — `docker run -p 3000:3000 ghcr.io/libredb/libredb-studio:latest` The canonical image. Zero-config: the admin password is printed to the log on first run. - **Docker Hub mirror** — `docker run -p 3000:3000 libredb/libredb-studio` A mirror for discoverability. GHCR above is the canonical registry. - **Helm chart** — `helm install libredb oci://ghcr.io/libredb/charts/libredb-studio` Published to the libredb.org repo, GHCR as OCI, and ArtifactHub. First-run credentials are printed to the pod log. - **Rancher Partner Charts** A certified chart in Rancher Partner Charts, with a SUSE Partner Certification listing. - **Homebrew tap** — `brew trust libredb/tap && brew install libredb/tap/libredb-studio` brew trust is required once on Homebrew 6+; run brew update first if the command is unknown. - **Snap Store** — `sudo snap install libredb-studio` Stable channel, amd64 and arm64. The admin password is printed to sudo snap logs libredb-studio. - **winget** — `winget install LibreDB.Studio` Portable zip with a bundled Node.js runtime — then run libredb-studio. - **Chocolatey** — `choco install libredb-studio` The same standalone zip as winget, from the Chocolatey community repository. - **FlatPark (Flatpak)** A signed Flatpak remote carrying org.libredb.Studio, repackaged from the official vendor build. - **Desktop app — AppImage & .deb** A desktop wrapper shipped as release assets: AppImage and a GUI .deb, x64 and arm64. - **Linux .deb / .rpm** Native server packages, attached to every release. - **AppImageHub** The catalog AppImage Pool and Zap read. It resolves the latest release itself, so the listing follows every release without a submission. - **Railway** A one-click template in Railway’s own catalog. - **CapRover** Listed in CapRover’s official one-click apps. - **Dokploy** In the Dokploy template catalog. - **Kubero** In the Kubero template catalog. - **Sealos** A template in the Sealos App Store. - **Cosmos** A servapp in the Cosmos marketplace. - **Unraid Community Applications** Installable from Unraid’s Community Applications tab. - **TrueNAS SCALE** In the TrueNAS SCALE community apps catalog. - **Fly.io** A fly.toml in the repository — fly launch reads it. - **Render** A render.yaml Blueprint in the repository. - **Koyeb** A deploy button in the repository README. It deliberately ships no default credentials — you supply your own. - **DigitalOcean Marketplace** Provisioned straight from DigitalOcean’s marketplace. The full channel inventory, including the update policy per channel, is at https://libredb.org/deploy. The canonical docker-compose.yml is served verbatim at https://libredb.org/docker-compose.example.yml and explained at https://libredb.org/docker-compose. ## The other product: LibreDB the database LibreDB is also a small embeddable multi-model database in TypeScript — one ordered key-value core with key-value, document and relational lenses over it, zero runtime dependencies, crash recovery proven by deterministic simulation testing. It is an early beta aimed at test and development data. Described at https://libredb.org/libredb-database. ## The product that is intended to cost money one day: LibreDB Platform Multi-tenant database access governance for teams — organisations, five-role RBAC, per-connection permissions and a query audit log, self-hosted. In beta, not sold today, and with no plan to sell it within the next year; the editor itself stays MIT and free. Described at https://libredb.org/platform. ## FAQ **What does "the tool goes to the data" actually mean?** Studio runs as a container inside the same private network as your database, and you reach it over a URL. Nothing is exposed to the internet, no SSH tunnel is dug, and the data never travels — only the query and its result do. **Which databases are supported?** Nineteen engines: PostgreSQL, MySQL, Oracle, SQL Server, SQLite, libSQL, DuckDB, ClickHouse, Apache Druid, Trino, MongoDB, Couchbase, Redis, LibreDB, Cassandra, Elasticsearch, OpenSearch, Prometheus and Apache Kafka — relational, document, key-value, wide-column, analytical, search, time-series, streaming and federated query. One of the nineteen is LibreDB itself, the embedded store the playground runs on, so the count you will see on the product listings is eighteen: those count the engines you point Studio at, not the one it carries. **Is anything held back from the open-source build?** No. OIDC single sign-on, ER diagrams, the AI assistant and the MongoDB and Redis drivers are all in the MIT build. What costs money is someone else running it for you; no capability moves across that line to create a reason to upgrade. **Why does each engine list what it does not do?** Because a feature list quietly breaks on the fourth engine. Capability flags come from the provider itself, so a control that cannot work is hidden rather than offered and then failed — Cassandra has no joins, search engines have no row editing, ClickHouse has no foreign keys to draw. **How do I install it?** One container: docker run -p 3000:3000 libredb/libredb-studio. There is also an npx package, a Helm chart, a certified chart in Rancher Partner Charts, an embeddable npm package and one-click templates for Railway, Dokploy, CapRover, DigitalOcean, Sealos and Fly.io — 33 channels, 26 of them live. **Does it work on a phone?** Yes. There is dedicated mobile navigation and a card view for results, because the query that matters is often the one you run on call, away from a laptop. **What does the database agent do?** You state an objective; the agent runs read-only, budgeted SQL and writes a report where every claim cites a result. It is available on PostgreSQL and SQLite. **How is it secured for a team?** OIDC single sign-on, role-based access control, an audit trail of every executed query, and risk analysis before a destructive statement runs. First boot generates its own secrets and prints them once; native channels bind to localhost by default.