Hi all, I'm building LibreDB Studio, an open-source (MIT) web-based database IDE. It already handles PostgreSQL, MySQL, MongoDB, Redis, Kafka, Prometheus and Elasticsearch from a single browser tab.

I've opened a PR that adds a read-only S3-compatible object storage provider:

https://github.com/libredb/libredb-studio/pull/1654

- Browse buckets and objects (tree + Keys panel)

- Object metadata and size-limited previews: text, JSON, NDJSON, CSV, TSV, gzip, Parquet, hex

- A read-only subset of `aws s3` / `aws s3api` commands in the console (write commands are rejected before any request is sent)

- Tested against MinIO, Garage, Silo and RustFS

Questions for MinIO users:

1. Does object storage belong in a "database editor", or is it out of scope?

2. Would browsing Parquet/CSV data on MinIO next to your databases actually help your workflow?

3. Is read-only the right starting point, or would you need write operations (upload/delete)?

4. Anything MinIO-specific (versioning, tagging, lifecycle, etc.) you'd want to see?

Honest feedback welcome. Thanks!

If you self-host Dokploy: you spin up a database, and then you want to look inside it. Today that usually means opening a port or setting up a tunnel, for every environment.
What if managing it were this easy instead?
I self-host Dokploy too, so I built an integration and recorded a short walkthrough. The video shows installing LibreDB Studio straight from the Add Database dialog, the managed databases showing up on their own, and opening a database in the editor signed in as my own user.
LibreDB Studio is open source, MIT licensed, and I maintain it. You can self-host it today from the repo or the 0.18.0 image, next to whatever platform you run.
The Dokploy integration itself is not shipped yet. I proposed it upstream as a feature request, Dokploy/dokploy#5598, and the video is a preview of what I built.
If this would be useful to you, follow or comment on the issue so the maintainers can see the interest.
Try LibreDB Studio, and tell me what you think.

Repo: https://github.com/libredb/libredb-studio

Demo: https://app.libredb.org

Youtube Demo!

Deploy it next to your database with Docker or Helm and open it in the browser. No SSH tunnels, no desktop client on every laptop.

Postgres, MySQL, Oracle, SQL Server, MongoDB, Redis, ClickHouse, DuckDB, Cassandra and more. MIT licensed, SSO and the AI assistant included.

Passei 11 dias investigando por que modelos open-weight pequenos falham em tarefas agentic de banco de dados. O resultado mais interessante foi que, em muitos casos, o problema não estava no modelo, mas no nosso próprio servidor.

Testamos 39 modelos open-weight rodando localmente + 1 modelo hospedado como controle, usando o modo agente do nosso SQL client em 6 tipos de tarefa.

Foram 8.199 execuções, 110.711 eventos de ledger e 14.008 chamadas de ferramentas recusadas.

Das 2.100 falhas atribuídas aos modelos no modo agente, 75,7% aconteceram em execuções que haviam chamado pelo menos uma ferramenta. Ou seja, os modelos estavam tentando executar as tarefas. Em muitos casos, estavam falhando na interface entre o modelo e as ferramentas.

Durante dez dias não conseguíamos entender exatamente o motivo. Nossos logs de produção registravam apenas o código da recusa, não os argumentos enviados pelo modelo. Quando começamos a capturar esses argumentos, encontramos cinco problemas no nosso próprio servidor.

O caso mais claro envolveu um modelo de 3B em uma tarefa de análise de dados: 0/5. Em todas as cinco execuções ele gerou o relatório corretamente, mas não apresentou a resposta.

Ao analisar os argumentos reais enviados pelo modelo, descobrimos que ele tinha as duas partes da resposta. O problema era o contrato das ferramentas: nosso servidor exigia um campo `presentation` em uma ferramenta, recusava o mesmo campo na ferramenta irmã com `"remove presentation"` e depois falhava a execução porque o campo estava ausente.

O contrato era contraditório.

Fizemos cinco mudanças no servidor, sem alterar nenhum modelo, prompt ou configuração de sampling. Seis modelos melhoraram entre 6 e 21 células em uma matriz de 30.

O paper é um preprint e ainda não foi peer reviewed. Estamos compartilhando também o código e o corpus para que os resultados possam ser reproduzidos.

Repo: https://github.com/libredb/libredb-studio

Preprint: https://arxiv.org/abs/2609.21341

Corpus, scorer e um verificador que regenera todas as figuras: https://huggingface.co/datasets/libredb/database-agent-runs

Se alguém aqui trabalha com agentes, MCP/tool calling ou avaliação de LLMs, eu gostaria bastante de ouvir críticas sobre a metodologia e os resultados

https://docs.yugabyte.com/stable/integrations/tools/libredb-studio/

https://github.com/libredb/libredb-studio

I've been working on the architecture of LibreDB Studio, a TypeScript-based database IDE that supports multiple SQL/NoSQL databases

while working on the provider layer, I ended up designing a fairly strict provider architecture to make adding new databases safer and reduce the amount of core code that needs to change

i wrote about the architecture here: https://libredb.org/blog/building-universal-database-provider-typescript/

the current process for adding a provider is documented here: https://github.com/libredb/libredb-studio/blob/main/docs/ADDING_A_PROVIDER.md

architecture is working reasonably well, but it raised a bigger question for me

currently, adding a new provider still means adding it to the main Libredb-Studio codebase. I'd like to eventually move toward something more like a plugin ecosystem:

- libredb studio provides a stable provider SDK/API.

- A third-party developer can implement a new database provider independently.

- The provider can be published as a package/library.

- Users can install or enable that provider without waiting for a new Libredb Studio release.

- The core application doesn't need to be modified every time a new database is supported.

Conceptually, something like:

libredb-studio

|

+-- Provider SDK / API

|

+-- PostgreSQL provider

+-- MySQL provider

+-- MongoDB provider

+-- Third-party provider

+-- ...

I'm considering different approaches for the distribution/discovery side as well: npm packages, a provider registry/marketplace, or some combination of these.

but I'm not sure where the right boundary is.

for example:

- Should the provider contract be a completely separate, versioned TypeScript SDK package?

- Is npm + a manifest/discovery mechanism enough, or does a dedicated registry/marketplace make more sense?

- How would you handle provider/API compatibility across LibreDB Studio releases?

- Should providers be dynamically loaded at runtime, or should they still be bundled/installed at build time?(for now: dynamic load)

- Since this is a web application, how would you approach the security/isolation implications of loading third-party provider code?

- Are there established architectures/projects that handle this problem particularly well?(I am not sure: selfhosted and system admin managed this OK, but I am confused, security/comfortable ...)

The goal isn't necessarily to build a huge plugin system. I'd prefer the smallest architecture that gives third-party developers a stable extension point.

I'd especially appreciate opinions from people who have designed plugin/extension systems for TypeScript/JavaScript applications in production.

What would you consider the "right" architecture for this?

1. Introduction: The Missing SPI in Modern Runtimes
2. The Problem Statement
3. Architecture Overview: The DatabaseProvider SPI & Adapter Pattern
4. Deep Dive: Resolving Core Engineering Challenges
   • Challenge 1: Zero-Overhead Dynamic Module Loading
   • Challenge 2: Unifying Heterogeneous Engine Schemas ("Object Surface API")
   • Challenge 3: AI Agent Isolation & Read-Only Execution Profiles
   • Challenge 4: Single-Writer File Locks & SSH Tunnel Forwarding
5. Code Walkthrough & Implementation Details
   • The Provider Contract (BaseDatabaseProvider)
   • The Factory & Cache Registry
   • Engine Adapter Case Studies (PostgreSQL, SQLite, Embedded LibreDB)
6. Key Takeaways & Lessons Learned

1. Introduction: The Missing SPI in Modern Runtimes

In mature enterprise ecosystems like Java or .NET, developer tools that interact with databases rely on standardized, runtime-level Service Provider Interfaces (SPIs):

• Java: java.sql.Driver, java.sql.Connection, java.sql.Statement, and java.sql.ResultSet (JDBC).
• .NET: System.Data.Common.DbConnection, DbCommand, and DbDataReader (ADO.NET).

In these environments, database vendors—whether Oracle, PostgreSQL, MySQL, or Microsoft SQL Server—author driver JARs or DLLs that conform strictly to these runtime interfaces. The GUI or client application calls standard APIs without needing to know low-level wire protocol nuances, connection pool nuances, or engine-specific error classes.

The JavaScript / TypeScript Gap

Node.js, Bun, and Deno lack a native, language-wide database driver standard equivalent to JDBC.

Instead, the npm ecosystem contains a fragmented collection of independent community drivers:

• PostgreSQL uses pg (node-postgres).
• MySQL uses mysql2.
• SQLite relies on native bindings like better-sqlite3, bun:sqlite, or node:sqlite.
• Oracle DB relies on oracledb.
• NoSQL databases like Redis (ioredis), MongoDB (mongodb), and Cassandra (cassandra-driver) use entirely different paradigms (document descriptors, key-value commands, binary buffers).

Building a universal, self-hosted database IDE or management platform in TypeScript requires solving this fundamental problem: How do you build a single, type-safe, performant, and secure application that can interact with 15+ relational, document, key-value, OLAP, and embedded database engines without a unifying runtime SPI?

This article explores how LibreDB Studio solved this challenge by engineering a unified DatabaseProvider architecture.

2. The Problem Statement

When building a universal database client in TypeScript, five major architecture constraints arise:

1. Heterogeneous Engine Paradigm: Relational databases (PostgreSQL, MySQL), Document databases (MongoDB), Key-Value stores (Redis), OLAP engines (ClickHouse, Trino, Druid), and Embedded engines (SQLite, u/libredb/libredb) have zero overlapping query languages or connection lifecycle models.
2. Cold Start & Memory Bloat: Statically importing driver dependencies for 15+ database engines on application startup would result in massive bundle sizes and unacceptable RSS memory footprints.
3. Schema Introspection Normalization: The UI requires a uniform object tree (Containers  Folders  Objects  Columns/Indexes). However, PostgreSQL uses pg_catalog, MySQL uses information_schema, SQLite uses pragma_* functions, Redis uses key prefixes, and embedded engines use custom catalog registries.
4. AI Agent Safety & Guardrails: With Text-to-SQL and AI database agents executing queries, the architecture must enforce database-native read-only boundaries (e.g., prohibiting destructive SQL or file system operations) at the connection layer.
5. Concurrency & Resource Lifecycle: Embedded engines (like SQLite or embedded LibreDB) enforce single-writer file locks (.lock). Attempting to open concurrent handles to the same file causes system crashes or connection locks.

3. Architecture Overview: The DatabaseProvider SPI & Adapter Pattern

To bridge this gap, LibreDB Studio implements a strict Adapter / Strategy Pattern centered around an abstract contract: BaseDatabaseProvider.

Core Design Rules

1. Zero Raw Protocol Drivers: The provider layer does not re-implement low-level TCP/socket wire protocols from scratch. Instead, it wraps mature, battle-tested npm driver packages.
2. No Heavy ORM Dependency for Targets: Target database queries (data browsing, schema inspection, explain plans) execute via raw SQL or native driver commands. ORMs (like Prisma or Drizzle) are avoided for target inspection to ensure zero abstraction overhead and maximum query control.
3. Unified Execution Lifecycle: Every provider implements a standardized contract covering connection pooling, query execution, unified schema introspection, health monitoring, and maintenance.

https://libredb.org/blog/building-universal-database-provider-typescript/

We're building **LibreDB Studio**, an open-source SQL editor, and one of our volunteer contributors raised an interesting question about how multiple SQL statements should behave when using the Run action.

We're trying to understand the actual habits and expectations of SQL users before making a decision, so I'd really like to hear how you use SQL editors in practice.

For example:

CREATE TABLE test (...);

INSERT INTO test VALUES (...);

SELECT * FROM test;

What would you expect when you click **Run**?

Some possible approaches:

1. **Run all statements*** `Run` executes everything in the editor.* `Run Selection` can be used when you only want part of it.
2. **Run the current statement*** `Run` executes the statement where the cursor is.* `Run All` executes the whole editor.
3. **Selection takes priority*** No selection : current statement* Selection : selected statements* `Run All` is available separately.
4. Other :)

there are also some interesting edge cases around this, especially when multiple statements are involved: should they run in a transaction by default, or should transaction handling always be explicit?

DBeaver, DataGrip, SSMS, pgAdmin, TablePlus, Toad, PL/SQL Dev, phpMyAdmin, etc. what behavior feels most natural to you? And what behavior are you already used to?

We're continuing the discussion on GitHub as well, if you'd like to see the original question or add to the discussion:

https://github.com/orgs/libredb/discussions/776

I am Mehmet, maintainer of LibreDB Studio. I am not Pakistani, so I will be upfront about why I am posting here: the project

needs contributors, and this sub is full of people who build things. That is the whole reason. Whether a merged PR is worth your time is your call, not mine to argue.

The project is LibreDB Studio: a web-based database client you run on your own server, 17 engines behind one interface, MIT, no paid tier, no per-seat licence, nothing to subscribe to.

If you just want the tool, that is the whole story.

The part that might be more useful: there are 15 issues tagged good first issue right now, and most are documentation-sized rather than heroic. Recent example of the path working - someone opened their first PR to add a Spanish README and it is merged.

What I can give: a review within a day, and a real merge, not a thank-you note.

What I cannot give: money, a job, or a referral. Nobody should pretend a merged PR is any of those.

github.com/libredb/libredb-studio

Happy to answer anything about the codebase, or about how the review works

I'm the maintainer of LibreDB Studio (MIT, self-hosted web DB GUI). This is not a launch post. I am stuck on a metric I cannot honestly farm.

The project is ten months old. Postgres.org lists it as a client; Redis, ClickHouse and Druid docs mention it. We keep a public distribution inventory (`distribution/channels.yaml`) because I treat “can you actually install this” as part of the product.

That file currently says : 26 live channels.** Live examples, not a tour: GHCR (canonical image) and Docker Hub (discoverability mirror), Helm and Rancher Partner Charts, OpenShift opereator, npm / Homebrew / Snap / winget / Chocolatey, DigitalOcean Marketplace, Railway, Dokploy, CapRover, TrueNAS, Unraid, plus a desktop AppImage. CasaOS, Umbrel and Portainer PRs are still open. Deprecated on purpose: Flathub declined the app under their generative-AI policy; we closed the PR rather than argue. Linux Flatpak users go through FlatPark instead.

On the credit / catalog side I have been accepted in places that reviewed the repo, the license, and the image. GCP is one of them (not in that live matrix yet). Smaller catalogs and some OSS support programs still bounce the same application with one number: **you need 10k GitHub stars.**

Numbers I can defend today (2026-09-02):

- GitHub stars: **390**

- GHCR `ghcr.io/libredb/libredb-studio` (canonical): **22.5k**

- Docker Hub `libredb/libredb-studio` (mirror): **75,978**

- Together that is **98.5k pulls of the same image across two registries**. I am not calling that 98k unique humans. CI, Kubernetes, and `latest` retags all count. I am also not stuffing npm into this total, `@libredb/studio` is a launcher, a few thousand downloads / 30 days.

People who pull from GHCR or Hub almost never open the GitHub repo, so they never star. A 10k-star gate is still 25× the badge. For a tool that is supposed to live next to a database, I do not know a clean way to close that gap that is not “go viral” or “put a star modal in the GUI.” I will not do the second one.

I know why the 10k checkbox exists. Coding-agent PRs are a flood. Reviewing them is unpaid hours. I get those PRs too, drive-by diffs that look finished and are not, “fixes” that do not compile, issues that are a paste from a chat. I close a lot of them. I am not asking anyone to lower their bar for slop.

What I am stuck on is that **stars do not measure that work.** A catalog cannot see that I rejected the junk and still shipped Helm, an operator bundle, and an image people actually pull. The gate I hit is a popularity badge, not a review-load badge.

If you have walked this:

1. Did any program accept registry pulls, a distro listing, or Helm instead of stars, or is 10k always a hard floor?
2. If you later crossed 10k, was it one front-page hit or years of boring use?
3. Is asking Docker users to star even legitimate?
4. If you maintain something and you found a program that scored review signal, tests, or distro listings instead of the star count, what did they actually ask for?

Inventory: https://github.com/libredb/libredb-studio/blob/main/distribution/channels.yaml

Affiliation: I’m the maintainer of LibreDB Studio.

For years the SQL workflow for a team looked like this, on every engine I touched (PostgreSQL, MySQL, Oracle, SQL Server, SQLite, MariaDB, Clickhouse ...):

- install a desktop client on each laptop

- VPN / SSH tunnel so the client can even see the box

- hunt schema in one pane, write the query in another

- run something that hangs and hope cancel actually kills it

- EXPLAIN in a second window

- onboard the next person by repeating the install

or try on their own web editor(pgAdmin, phpMyAdmin ...)

I got tired of the editor living on the laptop instead of next to the database, so I built a self-hosted browser SQL IDE. Deploy once (Docker / Helm / `npx "@libredb/studio"`, one-click with rancher, dokploy, digitalocean), open a URL, same UI for the engines above.

Not trying to replace DBeaver or DataGrip, different access model. Postgres is the reference implementation: pooled connections, explicit BEGIN/COMMIT/ROLLBACK with an auto-rollback timeout, cancel through pg_cancel_backend on the tracked PID. Schema tree stays usable on large catalogs (tables first, relationships second). Optional db-agent to SQL is schema-constrained and read-only runs go through BEGIN READ ONLY, not “trust the prompt.”

MIT. One command:

docker run -p 3000:3000 libredb/libredb-studio

If you try it, I actually want the unkind notes:

- does cancel / transaction rollback behave the way you’d expect on Postgres?

- what’s missing vs the desktop client you already live in?

- is a browser editor a non-starter for you, and why?

Source: https://github.com/libredb/libredb-studio

I'm the maintainer of LibreDB Studio.

Typical k8s setup around here: Mongo for the service, Postgres for the relational bits, Redis for cache, sometimes Elasticsearch. Compass on every laptop means either 27017 is public or you're maintaining an IP allowlist for two teams in two states. Both are bad.

The editor goes to the data. Helm it into the same cluster (or docker run it on the same network). Browsers talk to Studio over HTTPS + OIDC; only that pod opens Mongo. When nobody needs to debug, scale the GUI to zero, you don't flip the database public.

Mongo speaks MQL in the editor (find / aggregate / the usual writes). Same tab can open the Postgres and Redis next to it, which is the actual day for microservice/DevOps folks; not a Mongo-only admin panel.

MIT. Helm:

helm install libredb oci://ghcr.io/libredb/charts/libredb-studio

or:

docker run -p 3000:3000 libredb/libredb-studio

npx -y "@libredb/studio"

Curious what would make this usable on your cluster (ingress, Atlas, RBAC). What did I get wrong?

https://github.com/libredb/libredb-studio

Affiliation: I'm the maintainer of LibreDB Studio.

The stack I keep seeing on microservice teams is Postgres + Mongo + Redis + Elasticsearch. Kibana is the right UI for the ES cluster, Discover, dashboards, ES|QL, Fleet. I still use it. I got tired of a second desktop app for each of the other three.

LibreDB Studio is one browser UI for that set, self-hosted, Helm-installable next to the services. Elasticsearch here is the product's own POST /_sql on basic, mapping-driven index tree, read-only (this grammar cannot write). Not Query DSL, not ES|QL, not Discover.

docker run -p 3000:3000 libredb/libredb-studio

Also a Helm chart, so it can sit next to the cluster. Kibana does not come off the box.

If that four-store layout is yours: which of the four still forces you into a separate window?

I'm the maintainer of LibreDB Studio. I already posted the ClickHouse provider here: HTTP only (:8123 / :8443), no native driver on :9000.

https://www.reddit.com/r/Clickhouse/comments/1vls7n8/added_clickhouse_to_a_selfhosted_browser_sql_ide/

This is not another feature post. That same provider is now on ClickHouse's docs, under Visual Interfaces from Third-party Developers:

https://clickhouse.com/docs/integrations/connectors/tools/gui

Third-party listing, not an endorsement from ClickHouse Inc. I'm posting it so this community can tell me if the blurb is wrong — especially the HTTP surface and the system-table mapping (metrics / parts / query_log / processes).

Provider notes: https://github.com/libredb/libredb-studio/blob/main/docs/providers/clickhouse.md

Affiliation: I’m the maintainer of LibreDB Studio (open-source, self-hosted browser DB GUI).

We’re not trying to replace RedisInsight or redis-cli, those are great at being Redis-native.

The gap we care about is different: one self-hosted web IDE where Redis sits next to the other engines you already use (Postgres, MySQL, Mongo, Couchbase, ClickHouse, Druid …) in the same browser UI, same deploy, same login.

Redis is first-class there, mapped by convention (not fake SQL):

- “Tables” = key prefixes from SCAN (e.g. user:*), never KEYS * on big keyspaces

- “Rows” = keys; the query box runs real Redis commands (plain text or { "command", "args" })

- Any command via a generic call() path — GET / HGETALL / XADD / JSON.GET / modules

- Monitoring from INFO, SLOWLOG GET, CLIENT LIST alongside the SQL engines’ overview

Honest limits: schema SCAN is capped (bounded introspection), and a DEL in the command box is a real DEL - no fake read-only mode.

Try:

docker run -p 3000:3000 libredb/libredb-studio

# or: npx "@libredb/studio"

Repo: https://github.com/libredb/libredb-studio

Provider notes: https://github.com/libredb/libredb-studio/blob/main/docs/providers/redis.md

If you hop between Redis and a SQL/document store in the same day: would a shared web UI help, or do you still prefer a dedicated Redis tool per workflow?

Affiliation: I’m the maintainer of LibreDB Studio (open-source, self-hosted browser DB GUI).

Just shipped ClickHouse support. LibreDB is a web SQL/NoSQL editor you run on your own box, ClickHouse joins the existing engines in the same UI.

For ClickHouse specifically we speak only the HTTP interface (:8123 / :8443 with TLS). No native protocol on :9000, and no client driver dependency, each statement is a POST / via the runtime’s fetch.

A few design notes that might matter if you wire CH from a browser-facing app:

- Errors are classified by ClickHouse exception code, not HTTP status (ACCESS_DENIED comes back as 500).

- Mid-stream failures can still arrive as HTTP 200 with the real error in the trailer, we have to handle that path.

- Schema/introspection goes through system.tables / system.columns; MergeTree primary key shows up as the sparse primary index, not a row-level PK.

- Transactions aren’t exposed (nothing real to expose). Cancellation is KILL QUERY via maintenance, not a cancel handle on the statement.

Try:

docker run -p 3000:3000 libredb/libredb-studio

# or: npx "@libredb/studio"

Repo: https://github.com/libredb/libredb-studio

Provider notes: https://github.com/libredb/libredb-studio/blob/main/docs/providers/clickhouse.md