DBGate: One Database GUI for Your Whole Team

Every team has this setup, and every team pretends it is fine. One developer is on TablePlus, another swears by DataGrip, a third is SSHing into the box and running raw psql, and the new hire spent their first morning figuring out which VPN, which host, and which password gets them a look at the production database. Everyone has their own connection strings saved in their own tool, and nobody is quite sure who can see what.

And it holds together until the day it doesn't. Someone's laptop with every prod credential saved locally gets left in a taxi, or a contractor rolls off and you realize their copy of the database password is just... out there. The problem is not the tools. It is that database access is scattered across a dozen laptops instead of living in one place you control.

DBGate fixes that by being one database GUI, running on your own server, that the whole team opens in a browser.

What DBGate actually is

DBGate is an open-source database manager. The part that matters here is that it ships as a web app in a Docker container, so you run one instance and everyone connects to it through the browser. No local installs, no per-seat licenses, no fleet of laptops each holding a full set of production credentials.

It is not a toy, either. It speaks 20+ databases, including PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, SQLite, MongoDB, Redis, ClickHouse, CockroachDB, and Cassandra. So the same window works whether you are poking at a Postgres cluster, a Mongo collection, or a Redis cache.

What you get inside:

• A real SQL editor with code completion, query parameters, and saved history.
• Direct data editing in a spreadsheet-style grid, with batch updates.
• Master-detail views that follow foreign keys, so you can navigate related rows without hand-writing joins.
• A visual query designer that builds joins across tables (and even MongoDB collections) for you.
• Import and export across SQL, CSV, JSON, XML, NDJSON, Excel, and YAML.
• ER diagrams, schema compare, and backup/restore for the housekeeping work.

There is also an AI database chat that turns plain-English questions into SQL, and it asks before it runs anything, which is the correct default.

The cost angle nobody mentions

Per-seat database tools add up quietly. A paid GUI at a couple hundred dollars a seat per year, times a growing team, is a line item you eventually get asked about. DBGate is open-source, so the software itself has no license fee. You pay for the small server it runs on.

On Elestio that is a one-click deploy with the database storage, TLS, and backups handled, starting at around $11/month for the VM. One shared instance for the whole team, flat cost, no seat math. You can spin one up from the DBGate on Elestio page.

Getting connections right

The first thing to decide is how connections are stored. DBGate can hold saved connections on the server so the team shares a curated set, or you can pre-define them with environment variables so they are baked into the deployment and never typed by hand.

Here is the shape of pre-defining a Postgres connection at startup:

# docker-compose.yml (excerpt)
services:
  dbgate:
    image: dbgate/dbgate:latest
    restart: always
    ports:
      - "3000:3000"
    volumes:
      - dbgate-data:/root/.dbgate
    environment:
      CONNECTIONS: con1
      LABEL_con1: Production Postgres
      SERVER_con1: your-db-host
      USER_con1: readonly_app
      PASSWORD_con1: ${PROD_DB_PASSWORD}
      PORT_con1: 5432
      ENGINE_con1: postgres@dbgate-plugin-postgres
volumes:
  dbgate-data:

Notice the USER_con1: readonly_app line. That is the real trick to sharing a database GUI safely: DBGate does not grant permissions, your database does. Point shared connections at a role that can read but not drop tables, and the blast radius of "everyone can open this" shrinks to something you can live with. Keep the write-capable roles for the connections that genuinely need them.

On Elestio, the dbgate-data volume is persisted for you, so saved connections and query history survive restarts and updates.

Locking it down

One shared instance means one door, so put a lock on it. Two things to do on day one:

Get those two right and a shared GUI is safer than a dozen laptops each holding admin credentials, not more dangerous.

Troubleshooting

• Connection refused to your database: the DBGate container has to be able to reach the database host over the network. If the DB only allows certain IPs, add the DBGate server's address to its allowlist, and double-check the port.
• "Engine not found" errors: the engine string includes a plugin, like postgres@dbgate-plugin-postgres. The official image bundles the common ones, but if you typo the engine name the connection will not initialize.
• Saved connections vanish after an update: that means the /root/.dbgate volume was not persisted. On Elestio it is; on a hand-rolled Compose file, make sure you mounted it.
• A query editor session feels slow: usually the database, not DBGate. Check that you are pointed at a nearby replica for heavy read queries rather than the primary across a region.

One window for the whole team

The pitch is simple. Instead of database access smeared across everyone's laptop in a different tool, you get one instance you control, one place to manage who connects to what, and one flat bill instead of a pile of seats. Your new hire gets a URL and a login, not a scavenger hunt.

Spin one up on the DBGate on Elestio page, point it at a read-only role first, and share the link.

Thanks for reading ❤️ See you in the next one 👋