Are these the same server?

Yes — both are Bytebase's DBHub universal gateway. One DSN points at a SQLite file, the other at PostgreSQL, but the tools, transactions, and safety controls are shared.

Do I need a running database for the SQLite option?

No. SQLite is embedded and serverless, so you just point DBHub at a .db file path. The Postgres option needs a running PostgreSQL server reachable by its connection string.

SQLite (DBHub) vs DBHub (Postgres)

Both of these MCP servers are the same thing under the hood — Bytebase's DBHub, a universal, zero-dependency database gateway that speaks a single connection string and exposes a small, safe surface: execute SQL with transaction support and safety controls, and explore schema, tables, columns, indexes, and procedures. What differs is the engine the DSN points at. The SQLite entry aims DBHub at a SQLite database file (sqlite:///path/to/database.db), which makes it an easy way to hand an agent a local .db or bundled database with no server to run. The Postgres entry aims the same gateway at PostgreSQL and is now the recommended Postgres option since the legacy server-postgres package was archived. Because the codebase and tools are shared, the real decision is about the database itself — an embedded single-file store versus a full client-server relational engine. Here is how the two ends of DBHub compare for an agent.

How they compare

Dimension	SQLite (DBHub)	DBHub (Postgres)
Underlying engine	SQLite — a serverless, embedded, single-file database that needs no running process; perfect for local files and bundled data.	PostgreSQL — a full client-server relational engine with rich types, concurrency, and an extension ecosystem (pgvector, PostGIS).
Connection model	Point the DSN at a file path (sqlite:///path/to/database.db); the agent reads or queries the file directly.	Point the DSN at a Postgres connection string with host, credentials, and database; standard client-server access.
Concurrency and scale	Single-writer, embedded — ideal for local analysis, prototypes, and read-heavy bundled datasets, not high-concurrency apps.	Built for concurrent multi-client workloads and large datasets with mature indexing and transactions.
Tool surface	Identical DBHub tools: execute_sql with transactions and safety controls, plus search_objects for schema exploration.	The same DBHub tools and safety controls — the gateway behaves the same; only the dialect and engine behind the DSN change.
Best-fit task	Handing an agent a local SQLite file to explore and query with zero infrastructure.	Letting an agent work against a real Postgres database, with the richer SQL and types Postgres provides.

Verdict

Pick by the database your data lives in, because the server is the same DBHub gateway either way. Use the SQLite endpoint when you want to point an agent at a local .db file or a bundled dataset with no server to stand up — it is the lowest-friction way to give a model SQL access to embedded data. Use the Postgres endpoint when your data is in PostgreSQL and you want its concurrency, richer type system, and extension ecosystem; it is also the recommended Postgres MCP now that the legacy package is archived. The tools, transaction support, and safety controls are identical, so there is no workflow difference to weigh — choose the DSN that matches the engine you already run.

FAQ

Are these the same server?: Yes — both are Bytebase's DBHub universal gateway. One DSN points at a SQLite file, the other at PostgreSQL, but the tools, transactions, and safety controls are shared.
Do I need a running database for the SQLite option?: No. SQLite is embedded and serverless, so you just point DBHub at a .db file path. The Postgres option needs a running PostgreSQL server reachable by its connection string.