# DBHub: a two-tool MCP server for Postgres, MySQL, SQL Server, MariaDB and SQLite

> DBHub is Bytebase's minimal database MCP server. It loads two tools by default at a stated 1.4k tokens, talks to five database engines, and ships a web workbench alongside the MCP endpoint.

**bytebase/dbhub** — Token conscious database MCP server for Postgres, MySQL, SQL Server, MariaDB, SQLite.

- Repository: https://github.com/bytebase/dbhub
- Website: https://dbhub.ai
- Stars: 3,586 · Forks: 310
- Language: TypeScript
- License: MIT
- Published: 2026-08-21 · Updated: 2026-08-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/bytebase-dbhub

## What DBHub solves, and who it is actually for

Every MCP tool definition an agent loads is context it cannot spend on the task. Database servers that expose dozens of tools pay for that in tokens before a single query runs. DBHub's stated position is that it loads just 2 tools by default at 1.4k tokens, which the README contrasts with MCP Toolbox at 19.0k tokens across 28 tools and Supabase MCP at 19.3k tokens. Those are the project's own figures, not an independent measurement, but the direction is the point: fewer tool schemas, more room for the schema you are actually querying.

The audience follows from that. The README lists local development, non-technical access through curated read-only views, multi-database consolidation, and production troubleshooting. The second and fourth are the interesting ones. A read-only DSN pointed at a replica, exposed through Claude Desktop, gives a support person a way to ask questions without a SQL client. The README also notes DBHub is the official example in the Claude Code docs for connecting to PostgreSQL via MCP, which is a distribution advantage rather than a technical one.

## Two default tools, a TOML file, and a web workbench

The default surface is small. execute_sql runs queries with transaction support and safety controls, and search_objects walks schemas, tables, columns, indexes and procedures. The README describes the latter as using progressive disclosure, which is the mechanism that keeps it cheap: the agent asks for a narrow slice of metadata instead of pulling an entire schema dump into the conversation.

Three more tools exist but are opt-in: explain_sql returns an execution plan without running the query, health_check reports connection pool state and buffer cache hit ratio, and Custom Tools let you define reusable parameterized SQL operations in dbhub.toml. Opt-in is the right default here. A health check that reports cache hit ratios is useful on a production replica and noise on a laptop.

Configuration runs through TOML, with dbhub.toml.example in the repository root. Multi-connection support means one DBHub process can front several databases at once, which is the consolidation argument: replace one MCP server per engine with a single process. The repository also contains a frontend/ workspace and a workbench the README describes as a built-in web interface for executing queries, running custom tools and viewing request traces without an MCP client. Note that the frontend is always served over HTTP regardless of the transport setting, so starting DBHub in stdio mode still stands up a web listener.

## Installing DBHub and running a first query

The README's install line is a single npx invocation. This starts the MCP endpoint over HTTP on port 8080 against a Postgres DSN, and the same process serves the workbench frontend.

```bash
npx @bytebase/dbhub@latest --transport http --port 8080 --dsn "postgres://user:password@localhost:5432/dbname?sslmode=disable"
```

If you are wiring it into an MCP client that speaks stdio, drop the transport flag, since stdio is the default per .env.example. The DSN is not the only way in. Individual parameters exist because passwords containing @, :, / or # break URL parsing, and .env.example says so explicitly.

```bash
DB_TYPE=postgres
DB_HOST=localhost
DB_PORT=5432
DB_USER=postgres
DB_PASSWORD=my@password:with/special#chars
DB_NAME=mydatabase
```

Supported DB_TYPE values are postgres, mysql, mariadb, sqlserver and sqlite. For SQLite only DB_TYPE and DB_NAME are required, and DB_NAME is the file path. A SQLite DSN can also be sqlite::memory: or sqlite:///path/to/database.db. The repository ships a demo/employee-sqlite/ directory, which is the fastest thing to point at if you want to see search_objects return real table metadata before touching a production database. Building from source requires Node.js >= 22.5.0, because DBHub uses the built-in node:sqlite module, and the project uses pnpm 10.17.1.

## The HTTP transport does not authenticate clients

This is the limitation worth reading twice. In .env.example, the DBHUB_HOST variable defaults to 0.0.0.0, which listens on all interfaces, and the comment states plainly that DBHub does not authenticate HTTP clients. The recommended posture is to set DBHUB_HOST=127.0.0.1 and put nginx, Caddy or a firewall in front. The variable is prefixed with DBHUB_ specifically to avoid colliding with the generic HOST variable that some shells and CI systems set on their own, which is a sensible detail and also a hint that the default was chosen for convenience rather than for exposure.

There is DNS-rebinding protection through an allowed Host header list, and loopback addresses are always allowed. That guards against a browser being tricked into reaching a local instance. It is not authentication, and it does not help if you bind to a public interface.

The second limitation is scope. DBHub is a query and exploration gateway. Nothing in the README describes migrations, schema versioning, DDL review or change management, and that is Bytebase's other product. If your problem is coordinating schema changes across environments, DBHub is the wrong tool and the README does not pretend otherwise. Row limiting, read-only mode and query timeouts are guardrails against runaway reads, not a substitute for a change process.

## DBHub against MCP Toolbox and Supabase MCP

The README's own comparison table puts DBHub at 1.4k tokens and 2 default tools, MCP Toolbox at 19.0k tokens and 28 tools, and Supabase MCP at 19.3k tokens with all tools loaded. The difference in approach is breadth versus context budget. MCP Toolbox ships a large catalog of prebuilt tools, which means an agent can call a named operation instead of composing SQL, at the cost of carrying every one of those schemas in the window. DBHub makes the agent write SQL against two general tools and discover structure through search_objects.

Which is better depends on the agent. A model that writes reliable SQL benefits from the smaller surface. A workflow built around fixed, audited operations may prefer named tools, because a named tool is easier to constrain than free-form SQL. Supabase MCP is a different category: it is tied to Supabase as a platform, so it is only an alternative if your database already lives there. DBHub's engine list (PostgreSQL, MySQL, SQL Server, MariaDB, SQLite) is what makes it portable across an existing fleet, including the SQL Server instances that most MCP database servers ignore.

## Maintenance, licence and the upgrade path

DBHub is MIT licensed, which permits commercial use and modification, though the usual caveat applies: the licence text governs, and this is not legal advice. The repository is not archived. The last push was on 2026-08-21, the same day as the v1.2.1 release, and v1.2.0 and v1.1.0 both landed on 2026-07-31.

Upgrade cost is low by design. The npx command pins @latest, so a restart picks up the newest release; if you want reproducibility, pin a version instead. The package.json version field reads 1.2.4 while the most recent release listed is v1.2.1, and the repository has a sync-version script plus a version hook that updates plugin/.claude-plugin/plugin.json, plugin/.mcp.json and server.json. That hook exists because the same version has to be consistent across the npm package, the Claude Code plugin and the MCP bundle. If you install through the MCP Bundle or the Claude Code plugin rather than npx, your upgrade path runs through those artifacts, and the README does not document rollback for any of them.

The build is a pnpm workspace with a frontend package, so self-hosting from source means building both halves: generate API types, run tsup for the backend, then build the frontend. The Dockerfile does this in a builder stage and deploys production dependencies with pnpm deploy --filter=dbhub --prod --legacy to keep the runtime image small.

## Conclusion

Adopt DBHub if you want one MCP process covering several engines and you care about how much of the context window the tool definitions consume. Skip it if you need authenticated remote access out of the box, or if your work is mostly writing and migrating schemas rather than reading them. Before rolling it out, check the guardrail defaults in dbhub.toml.example, confirm which tools are opt-in, and read the DBHUB_HOST note in .env.example, because the HTTP transport does not authenticate clients.

## FAQ

### What is DBHub?

It is a minimal MCP server from Bytebase that connects MCP-compatible clients to PostgreSQL, MySQL, MariaDB, SQL Server and SQLite. The README describes it as token efficient, loading 2 tools by default at 1.4k tokens, with explain_sql, health_check and custom tools available as opt-ins.

### what is dbhub

The same project: a database gateway that speaks MCP, ships a built-in web workbench, and supports multiple simultaneous connections through a TOML configuration file. It is MIT licensed and written in TypeScript.

### what is dbhub io

dbhub.ai is the project's homepage, linked from the README. It hosts the installation guide, the command-line options reference, the TOML configuration docs, the tool pages and the workbench documentation.

### Does DBHub work with VS Code?

The README lists VS Code among the MCP-compatible clients DBHub targets, alongside Claude Desktop, Claude Code and Cursor. Any client that speaks MCP over stdio or HTTP can connect, since DBHub exposes standard MCP tools rather than a client-specific integration.

### What is a DBHub alternative?

The README's comparison table names MCP Toolbox and Supabase MCP. MCP Toolbox loads 28 tools at 19.0k tokens by default, and Supabase MCP loads all tools at 19.3k tokens, against DBHub's 2 tools at 1.4k tokens.

## Sources

- [Official documentation](https://dbhub.ai)
- [Official README](https://github.com/bytebase/dbhub#readme)
- [Project repository](https://github.com/bytebase/dbhub)
- [Release notes](https://github.com/bytebase/dbhub/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bytebase-dbhub