Self-hosted browser GUI for SQLite, Postgres, Mongo, Redis, ClickHouse, Druid... now on their official tool lists

[u/cevheribozoglan]

Affiliation: I’m the maintainer of LibreDB Studio.

Most of the GUI conversation here is Postgres which is fair, but a lot of us also keep Redis, ClickHouse, or Druid in the same week.

I was tired of bouncing between desktop clients and per-engine admin UIs, so I built a self-hosted browser editor that talks to all of them from one place (plus MySQL, Oracle, SQL Server, MongoDB, Cassandra, Elasticsearch and more...).

Not claiming to replace DBeaver/DataGrip. Different access model: it deploys next to the data(kubernetes), not onto every laptop.

Third-party listing, for context:

• PostgreSQL project news + clients catalogue

https://www.postgresql.org/about/news/libredb-studio-an-open-source-self-hosted-sql-ide-for-postgresql-in-the-browser-3368/

• Also in official Redis, ClickHouse, and Apache Druid tool docs

MIT, Docker/Helm/ `npx "@libredb/studio"`. Quick path: `docker run -p 3000:3000 libredb/libredb-studio`

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

[u/maekoos]

what does ”encrypted” even mean on your sign in page? And you seem to be using development keys in production…

[u/cevheribozoglan → u/maekoos]

Both correct, and thanks for actually digging.

Dev keys: you're right. The demo tenant's Google social connection was still on Auth0's shared development keys, our own Google OAuth client(demo-client) is in place now. Nothing about that tenant ships in the product; self-hosted installs point at their own IdP (Keycloak, Okta, Entra ID, Auth0, whatever), or just use the built-in local auth, which is the default.

"Encrypted": that badge named no subject and I can't defend it, so it's off the page. What actually happens, since it's worth being precise about: with STORAGE_PROVIDER=sqlite|postgres, saved DB passwords, connection strings, TLS client keys and SSH keys/passphrases are encrypted at rest with AES-256-GCM (HKDF-derived key). The public demo deliberately does not run that, it's on the default local provider, so connections are never persisted server-side at all; they live in your own browser's localStorage and are sent with each query only to open the pool, never stored. That's on purpose: nobody's throwaway demo connection can end up visible to the other visitors.

[u/punk_dev → u/cevheribozoglan]

thanks claude

[u/cevheribozoglan → u/[deleted]]

That's the intended team path: Studio sits in the cluster, people auth to the UI (OIDC or local JWT), and the database only sees Studio.

Two different "sessions":

- Browser: one JWT cookie per person. No cap on how many can be logged in.

- Database: one pool per connection.id in the Node process, shared by everyone using that connection. Postgres defaults to min 2 / max 10, 30s idle, 60s acquire, 60s statement_timeout. Idle providers drop after 30 minutes. Redis is a single lazy connection, not a pool.

So if you seed a managed "prod-postgres" that every dev sees, ten people share one pool of 10. That's the "nobody gets a laptop tunnel" model. If each person saves their own connection record, each id gets its own pool of 10, and it multiplies.

The other budget is HTTP, not Postgres: 120 query-bucket requests / 60s, keyed on username, per process. Helm defaults to replicaCount: 1; a second replica is a second cache and a second set of pools against the same database.

We don't hide write buttons per user or enqueue queries across the team. The database sees N multiplexed clients from Studio, not N DBeaver processes.

For your team, is the shared pool the feature (Studio as the only client), or do you need a hard cap per person on top of that?

[u/cevheribozoglan → u/[deleted]]

Worth being precise about what that shared "connection" actually is, because it isn't a Postgres pool on every engine:

- SQLite: no pool. One file handle. WAL can take another reader in-process; there is no connectionLimit to turn.

- libSQL / Turso: no pool and no held session. Each statement is one HTTP POST to sqld / Turso Cloud (Hrana /v2/pipeline). Ten people querying is ten requests, not ten checkouts.

- DuckDB / embedded LibreDB: singleWriterFile. A second open of the same file is refused, including read-only.

- Postgres / MySQL: real pool, min 2 / max 10.

- MongoDB: the driver's MongoClient pool, same min/max > maxPoolSize / minPoolSize.

- Redis: one lazy ioredis connection, not a pool.

- ClickHouse (and Couchbase): same HTTP shape as libSQL, one request per statement.

So a seeded Postgres that every dev sees is ten people sharing one pool of 10. A seeded Turso database is ten people sharing one HTTP client. If each person saves their own connection record, only the pooled engines multiply.

[u/cevheribozoglan]

also try demo without local install : https://app.libredb.org/