DbGate: one database client for sixteen engines, plus a scripting API

Sixteen engines, split between the free core and Premium

The supported database list is the first thing to read, because it is where the product boundaries sit. In the free tier the README lists MySQL, PostgreSQL, SQL Server, Oracle, MongoDB, Redis, SQLite, CockroachDB, MariaDB, ClickHouse, Apache Cassandra, DuckDB and Firebird. Four more carry a Premium marker: Amazon Redshift, CosmosDB, libSQL/Turso and Firestore.

That split is drawn at the engine level rather than the feature level, which is a deliberate choice. It means you are never blocked from connecting to a database because of a paywall on an unrelated capability, and equally it means the more exotic engines are exactly the ones the author has chosen not to fund. For most people the free list already covers everything, since the common ground is well served.

The repository topics match the list closely, which is a reasonable sanity check that the support claim is real rather than aspirational: cassandra, clickhouse, cockroachdb, cosmosdb, duckdb, firebird, firestore, libsql, mariadb, mongodb, mysql, oracle, postgresql, redis, sql-server and sqlite all appear. DbGate is at 7322 stars and 473 forks, GPL-3.0, on `master`, last pushed 2026-09-21.

Desktop app, Docker container, or an npm import

The distribution story is unusually broad for a database tool, and it is the reason the project has held up over years. The README offers a downloadable application for Windows, Linux and Mac, an online demo at demo.dbgate.org, a web version as the `dbgate-serve` npm package, a Docker image, and a DbGate Community build.

The design goals section states the reason plainly: platform independent, running either as a web application in a single Docker container on a server or as an Electron application on a desktop. The stack underneath is Svelte for the frontend, NodeJs and ExpressJs for the backend, and Electron for the app shell.

The part that is genuinely unusual is the third option. DbGate is built out of standalone npm packages, so scripts can run without the application at all, and the README gives CSV export as the example, pointing at the `dbgate-plugin-csv` package on npm. That means the same code that powers a button in the UI can be called from your own Node script, which turns a GUI tool into a library you can put in a cron job.

Foreign-key-aware browsing is the actual differentiator

Most database clients are a grid with a SQL editor attached. DbGate's own answer to why it is different leads with that grid, listing browse with filtering and Excel-like filters, table data editing with a SQL change script preview, schema editing for indexes and keys, and schema compare and synchronize.

But the README's stated reason to be different is relation-aware data browsing: master and detail views, foreign key lookups, expanding columns from related tables in a flat data view, and an expandable form view for wide tables. If you have ever been annoyed that a join needs to be written by hand to check what a foreign key points at, that is the feature you are buying.

Two more are worth naming. Query perspectives give a nested table view over complex relational data, described as something like a query designer for MongoDB, which is an odd and useful idea when your data is not actually MongoDB. And there is a visual query designer for building SQL without writing it, including complex conditions like WHERE NOT EXISTS.

Alongside those: an SQL editor with a formatter, completion and a join utility, a Mongo JavaScript editor with NodeJs syntax, a Redis tree view with script generation, JSON view on MongoDB collections, ER diagrams, charts with HTML export, and GEO data on maps. There is also an AI powered database chat listed in the features.

Import, export, NDJSON archives and a data viewer

The data movement features are the ones that get used daily and rarely get talked about. DbGate imports and exports CSV, Excel, JSON, NDJSON, XML and DBF, and it offers batch import and export at the application level rather than only per table.

NDJSON gets special treatment, appearing in three separate places in the feature list. Archives are backups stored as NDJSON files on the local filesystem, or on the DbGate server when running the web application. There is a dedicated NDJSON viewer and editor that lets you browse and edit both data and structure directly on NDJSON files, with a note that it works for large ones too.

That combination is a genuine architectural choice rather than a feature bullet. If you can export to NDJSON and read NDJSON back in the same tool, then the file format becomes an interchange layer between DbGate and everything else, and a database backup is a set of plain text files you can diff, grep and commit.

Data editing is safe by default in at least one respect: table data edits go through a SQL change script preview, so you see the statement before it runs rather than after it has already changed your data.

A monorepo with per-engine plugins and an in-house API layer

The repository is a yarn workspaces monorepo, and the script list in package.json shows how the pieces divide. The workspaces are `packages/*`, `plugins/*` and `integration-tests`, and the scripts start each one in isolation:

+    "start:api": "yarn workspace dbgate-api start | pino-pretty",
+    "start:app": "cd app && yarn start | pino-pretty",
+    "start:web": "yarn workspace dbgate-web dev",
+    "start:sqltree": "yarn workspace dbgate-sqltree start",
+    "start:tools"
+

The `start:api:*` family is where the architecture shows. There are separate entry points for a portal mode, single database mode, authentication, database login, storage, storage built, Azure, and team mode for the end to end tests. That is a server with several deployment shapes rather than one web app, which is what you would expect from something sold both as a desktop application and as a self-hosted team server.

The tree reinforces it: `app/`, `common/`, `packages/`, `plugins/`, `docker/`, `patches/`, `e2e-tests/`, `integration-tests/`, `test-api/`, `translations/` and `workflow-templates/`. There are also release helper scripts at the root, `setCurrentVersion.js`, `setUpdaterChannel.js`, `generatePadFile.js` and `adjustPackageJson.js`, plus `AGENTS.md` and `CLAUDE.md`. Pinned Node versions live in `.node-version` and `.nvmrc`.

Version 7.3.0 shows where the paid features are heading

The current release is 7.3.0, published 2026-09-15, and the notes are short enough to read in full. Cloudflare D1 support arrived, covering database discovery, SQL execution and schema browsing, marked Premium. Google sign-in came with optional access restrictions and role synchronisation based on Google groups, marked Team Premium. Anonymous usage analytics were added as an opt-in with a consent prompt and a toggle in settings, and database connection credential protection was improved.

Read together, those four items describe where the product is going. D1 and Firestore are serverless and edge databases, which is the same direction as libSQL and Turso. Google Workspace group sync and access restrictions are team administration features, which is the shape of a paid product sold per organisation rather than per person. And the consent-prompted analytics are a normal consequence of a project that now has paying business customers.

The 462 open issues against 7322 stars is a busy tracker, and the release list shows premium beta tags shipping alongside stable ones, so expect a fast-moving project. The README also asks for contributions in non-code ways, including creating plugins, writing tutorials, adding SQL scripts to the public knowledge base, and building themes for DbGate Cloud.

Editorial conclusion

DbGate earns its place when you jump between database engines daily, because the alternative is a separate client for each one and the muscle memory never carries over. The design bets on that: every engine is a published npm plugin, the same import works from the app or from a script, and the web deployment is one container. The GPL-3.0 licence and the free core mean the client itself costs nothing, while some engines and team features sit behind Premium. The features people underrate are the ones built around foreign keys, master and detail views and query perspectives, which are what separate it from a generic SQL grid. Start with the downloadable app for a single connection, use the node scripting interface when you want the same logic in cron, and read the plugin development docs before assuming an engine you need is missing.

Frequently asked questions

Official sources

1. dbgate/dbgate on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases