LibreDB Studio: a self-hosted SQL IDE that runs next to the database instead of on your laptop
One browser tab for PostgreSQL, MySQL, Oracle, SQL Server, MongoDB, Redis, SQLite, Couchbase, ClickHouse, Druid, DuckDB, Turso and more. An open-source SQL IDE with SSO, audit trail and AI-assisted queries MIT licensed, with nothing held back behind an enterprise wall.
At a glance
- What is it?
- LibreDB Studio is an MIT-licensed, browser-based database editor that ships as a container, Helm chart or npm package and speaks to sixteen engines through one interface. The interesting part is not the engine count, it is that SSO, ER diagrams and the AI agent sit in the same licence as everything else.
- Who is it for?
- Adopt LibreDB Studio if your databases sit behind a private network and you need one browser tab that reaches all of them without distributing desktop clients or buying per-seat licences, and if you are willing to run it as a container or Helm release yourself. Do not adopt it if you need a fully read-write client for Druid, Elasticsearch or OpenSearch, or if Cassandra row counts are part of how your team works.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 16, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is network topology, not SQL editing
Most teams do not struggle to write SQL. They struggle to reach the database that holds it. The README describes the pattern plainly: you create a Postgres on a managed platform, it is ready in forty seconds, and then you want to look inside it. The options are to open a port to the internet, dig an SSH tunnel, or install a desktop client on every machine that needs one. Each of those moves the boundary of your network outward.
LibreDB Studio inverts that. It is deployed next to the data as a container, a Helm chart, a Rancher or OpenShift operator, a one-click PaaS template, or embedded through npm inside your own product. The README states the intent directly: nothing has to face outward. That framing tells you who the project is for. It is for platform and infrastructure engineers who already run Kubernetes or a container host, who have databases in private subnets, and who are tired of provisioning desktop licences for people who need to run one query.
The project is listed by the PostgreSQL project in its news, clients wiki, software catalogue and community GUI tools guide, and also appears in the official Redis, ClickHouse, MariaDB, Trino and Apache Cloudberry documentation. Those listings are distribution facts, not quality claims, but they do tell you the project has been reviewed by the maintainers of the engines it connects to.
Sixteen engines behind one explorer, with three that cannot write
The engine list is PostgreSQL, MySQL, Oracle, SQL Server, SQLite, libSQL, DuckDB, MongoDB, Redis, Couchbase, ClickHouse, Druid, Elasticsearch, OpenSearch, Trino and Cassandra. The README says all sixteen share the same explorer, with ER diagrams, schema diff and monitoring available wherever the engine has something to report. That conditional is doing real work, and the project is unusually explicit about where it applies.
Three engines are read-only because their own query languages are. Druid, Elasticsearch and OpenSearch have no UPDATE and no CREATE TABLE in the grammar. Rather than letting those controls fail at click time, LibreDB Studio reports them as unsupported. That is a small design decision with a large effect on trust: the UI tells you what the engine cannot do instead of discovering it through an error message.
Cassandra is the newest connector and the one that deliberately reports the least. The README states that Cassandra publishes no row count and no size that is true, so the object browser shows neither rather than a wrong number. The estimate it does publish counts partitions from flushed files, and the README gives a concrete example: it read 143 for a 500-row table. That is the kind of detail most database tools bury. Publishing it in the README is a statement about how the maintainers want the tool to be judged.
Trino is the other outlier. It is a query engine rather than a database, so it declares no keys and no indexes, and it reports bytes as belonging to the systems behind its connectors rather than to Trino itself. If your mental model of a schema browser assumes primary keys exist, Trino will not fit it.
Getting a running instance takes one command
The README gives two zero-clone paths. The recommended one is Docker:
docker run -p 3000:3000 ghcr.io/libredb/libredb-studio:latest
The alternative requires Node.js 24 or newer and no Docker:
npx @libredb/studio
After that you open http://localhost:3000. On first run the admin password is printed to the log, which the README describes as zero-config. That is convenient and it is also the first operational decision you have to make: whoever can read the container log at startup can read the admin password. Capture it, then change it.
The README also points to Helm, Homebrew, Snap, winget and deb/rpm packages under its install options section, and the release history shows a Helm chart versioned separately from the application. The most recent entries are chart 0.1.63 tracking app 0.15.0, chart 0.1.62 tracking the same app version, and application release 0.15.0. Chart and app versions moving independently is normal for Helm, but it means your upgrade procedure has to check both numbers rather than assuming they match.
There is a public test instance at app.libredb.org behind OIDC and a second at trial.libredb.org behind JWT with posted credentials. The README says both come with a pre-configured PostgreSQL database through what it calls seed connections. That is the fastest way to see the interface before you commit to a deployment, and it costs nothing to try.
The AI agent is read-only by design, and it uses your model
The README describes an agent that takes a stated question, drafts SQL, reads the results and continues from there. Two constraints are attached to it. The first is that it is read-only. The second is that it runs against your own model rather than a hosted service chosen by the vendor. The README's overview section truncates mid-sentence at "and writ", so the full description of the agent's capabilities is not available in the material I have. What can be confirmed is that the agent is read-only and that model selection is yours.
That combination matters for anyone whose databases hold regulated data. A read-only agent cannot issue an UPDATE because the capability is not there, which is a structural guarantee rather than a prompt instruction. Bringing your own model means query text and result data go to an endpoint you chose, which is the difference between a tool your security team can approve and one it cannot.
The README also makes an architectural argument for the licence. It says MIT is not generosity here but a requirement: you cannot place a per-seat licensed, feature-gated tool into every environment you own. That is a fair reading of how self-hosted software spreads inside an organisation. The moment a tool has a paid tier, every new deployment becomes a procurement conversation.
Where the sixteen-engine promise thins out
The honest limitations are the ones the project states itself. Three engines cannot write, so if your workflow depends on editing data in Elasticsearch or Druid through a GUI, this is the wrong tool and no amount of interface consistency will change that. Trino declares no keys and no indexes, so schema navigation there is a different experience from PostgreSQL. Cassandra shows no row count and no size, which is correct behaviour and also a real constraint if your team relies on a count to sanity-check a table.
Beyond the engine matrix, the deployment model is the limitation. A self-hosted IDE is a service you now operate. It has a container image, a Helm chart, an admin password printed to a log, and a network position that lets it reach every database you point it at. That is a meaningful concentration of access, and the README's own framing (deploy next to the data, nothing faces outward) is only true if you actually keep it inside the network boundary.
The version cadence is also worth noting. The releases shown span 0.15.0 and chart 0.1.63 within days of each other. Frequent releases on a 0.x line mean the API surface and the deployment artefacts are still moving. Plan for upgrades rather than treating an install as permanent.
How it differs from a desktop client like DBeaver
The obvious comparison is a desktop SQL client. DBeaver is the reference example: a Java application installed on each engineer's machine, with a large driver ecosystem and local credential storage. The difference is not feature depth. It is where the connection lives.
With a desktop client, the connection originates from the engineer's laptop. Reaching a database in a private subnet means a VPN, a bastion host or an SSH tunnel, and the credentials sit on the endpoint. With LibreDB Studio, the connection originates from a container inside your network. The browser talks to the container, and the container talks to the database. No tunnel is needed, and no driver is installed per machine.
That trade has a cost. A desktop client keeps working when your cluster is down, and it stores connection profiles locally where an individual controls them. LibreDB Studio centralises access, which is exactly why it can offer SSO and an audit trail in the same MIT build, and exactly why it becomes a service you have to keep running. The README lists SSO, audit trail and AI-assisted queries as part of the same licence as everything else, with nothing behind an enterprise wall.
If your databases are already reachable from developer laptops and nobody objects to local credential storage, a desktop client is simpler and has no operational surface. If they are not, the desktop client is the thing generating the tunnel requests.
Who should run this, and what to check first
The fit is a team that already operates containers or Kubernetes, has databases in private networks, and wants one browser tab covering PostgreSQL, MySQL, Oracle, SQL Server, MongoDB, Redis, ClickHouse and the rest without distributing desktop software or negotiating per-seat licences. The MIT licence removes the procurement step, and the SSO and audit trail features are in that same build rather than a paid tier.
The misfit is a team that needs full read-write access to Druid, Elasticsearch or OpenSearch, or that depends on accurate Cassandra row counts. It is also a poor fit for a single developer with one local database, where `npx @libredb/studio` works but a desktop client would involve less upkeep.
Before deploying, verify the things the README cannot verify for you. Confirm that your target engines and their versions appear in the supported list. Decide how the first-run admin password will be captured from the container log and rotated. Confirm which model the read-only agent will call and which database role it will use, since read-only is a property of the agent and not a substitute for a restricted role. Then check whether you are installing the application release or the Helm chart, because they carry separate version numbers.
Editorial conclusion
Adopt LibreDB Studio if your databases sit behind a private network and you need one browser tab that reaches all of them without distributing desktop clients or buying per-seat licences, and if you are willing to run it as a container or Helm release yourself. Do not adopt it if you need a fully read-write client for Druid, Elasticsearch or OpenSearch, or if Cassandra row counts are part of how your team works. Before rolling it out, verify three things on your own infrastructure: that the admin password printed on first run is captured and rotated, that your target engines appear in the supported list at the version you run, and that the read-only agent is pointed at a model and a database role you are comfortable with.
Community notes