What is DBHub is a universal database gateway implementing the Model Context Protocol (MCP) server interface.?
DBHub is a universal database gateway implementing the Model Context Protocol (MCP) server interface. This gateway allows MCP-compatible clients to connect to and explore different databases. It supports various databases including PostgreSQL, MySQL, MariaDB, SQL Server, and SQLite. DBHub can be run in demo mode with a sample employee database and supports SSH tunneling for secure connections.
Documentation
[!NOTE]
Brought to you by Bytebase, open-source database DevSecOps platform.
DBHub is a universal database gateway implementing the Model Context Protocol (MCP) server interface. This gateway allows MCP-compatible clients to connect to and explore different databases.
This provides an additional layer of security when connecting to production databases.
SSL Connections
You can specify the SSL mode using the sslmode parameter in your DSN string:
Database
sslmode=disable
sslmode=require
Default SSL Behavior
PostgreSQL
✅
✅
Certificate verification
MySQL
✅
✅
Certificate verification
MariaDB
✅
✅
Certificate verification
SQL Server
✅
✅
Certificate verification
SQLite
❌
❌
N/A (file-based)
SSL Mode Options:
sslmode=disable: All SSL/TLS encryption is turned off. Data is transmitted in plaintext.
sslmode=require: Connection is encrypted, but the server's certificate is not verified. This provides protection against packet sniffing but not against man-in-the-middle attacks. You may use this for trusted self-signed CA.
Without specifying sslmode, most databases default to certificate verification, which provides the highest level of security.
Example usage:
postgres://user:password@localhost:5432/dbname?sslmode=disable
# Require SSL without certificate verification
postgres://user:password@localhost:5432/dbname?sslmode=require
# Standard SSL with certificate verification (default)
postgres://user:password@localhost:5432/dbname
SSH Tunnel Support
DBHub supports connecting to databases through SSH tunnels, enabling secure access to databases in private networks or behind firewalls.
Using SSH Config File (Recommended)
DBHub can read SSH connection settings from your ~/.ssh/config file. Simply use the host alias from your SSH config:
DBHub will automatically use the settings from your SSH config, including hostname, user, port, and identity file. If no identity file is specified in the config, DBHub will try common default locations (~/.ssh/id_rsa, ~/.ssh/id_ed25519, etc.).
Note: When using SSH tunnels, the database host in your DSN should be the hostname/IP as seen from the SSH server (bastion host), not from your local machine.
Configure your database connection
You can use DBHub in demo mode with a sample employee database for testing:
npx @bytebase/dbhub --demo
[!WARNING]
If your user/password contains special characters, you need to escape them first. (e.g. pass#word should be escaped as pass%23word)
For real databases, a Database Source Name (DSN) is required. You can provide this in several ways:
[!WARNING]
When running in Docker, use host.docker.internal instead of localhost to connect to databases running on your host machine. For example: mysql://user:[email protected]:3306/dbname
DBHub supports the following database connection string formats:
HTTP server port (only applicable when using --transport=http)
8080
readonly
READONLY
Restrict SQL execution to read-only operations
false
demo
N/A
Run in demo mode with sample employee database
false
ssh-host
SSH_HOST
SSH server hostname for tunnel connection
N/A
ssh-port
SSH_PORT
SSH server port
22
ssh-user
SSH_USER
SSH username
N/A
ssh-password
SSH_PASSWORD
SSH password (for password authentication)
N/A
ssh-key
SSH_KEY
Path to SSH private key file
N/A
ssh-passphrase
SSH_PASSPHRASE
Passphrase for SSH private key
N/A
The demo mode uses an in-memory SQLite database loaded with the sample employee database that includes tables for employees, departments, titles, salaries, department employees, and department managers. The sample database includes SQL scripts for table creation, data loading, and testing.
The project uses Vitest for comprehensive unit and integration testing:
Run all tests: pnpm test
Run tests in watch mode: pnpm test:watch
Run integration tests: pnpm test:integration
Integration Tests
DBHub includes comprehensive integration tests for all supported database connectors using Testcontainers. These tests run against real database instances in Docker containers, ensuring full compatibility and feature coverage.
Prerequisites
Docker: Ensure Docker is installed and running on your machine
Network Access: Ability to pull Docker images from registries
Running Integration Tests
Note: This command runs all integration tests in parallel, which may take 5-15 minutes depending on your system resources and network speed.
pnpm test:integration
pnpm test src/connectors/__tests__/postgres.integration.test.ts\n\n# Run only MySQL integration tests
pnpm test src/connectors/__tests__/mysql.integration.test.ts\n\n# Run only MariaDB integration tests
pnpm test src/connectors/__tests__/mariadb.integration.test.ts\n\n# Run only SQL Server integration tests
pnpm test src/connectors/__tests__/sqlserver.integration.test.ts\n\n# Run only SQLite integration tests
pnpm test src/connectors/__tests__/sqlite.integration.test.ts\n\n# Run JSON RPC integration tests
pnpm test src/__tests__/json-rpc-integration.test.ts
All integration tests follow these patterns:
Container Lifecycle: Start database container → Connect → Setup test data → Run tests → Cleanup
Shared Test Utilities: Common test patterns implemented in IntegrationTestBase class
Database-Specific Features: Each database includes tests for unique features and capabilities
Error Handling: Comprehensive testing of connection errors, invalid SQL, and edge cases
Troubleshooting Integration Tests
Container Startup Issues:
docker ps
# Check available memory
docker system df
# Pull images manually if needed
docker pull postgres:15-alpine
docker pull mysql:8.0
docker pull mariadb:10.11
docker pull mcr.microsoft.com/mssql/server:2019-latest
SQL Server Timeout Issues:
SQL Server containers require significant startup time (3-5 minutes)
Ensure Docker has sufficient memory allocated (4GB+ recommended)
Consider running SQL Server tests separately if experiencing timeouts
Network/Resource Issues:
pnpm test:integration --reporter=verbose
# Run single database test to isolate issues
pnpm test:integration -- --testNamePattern="PostgreSQL"
# Check Docker container logs if tests fail
docker logs <container_id>
Pre-commit Hooks (for Developers)
The project includes pre-commit hooks to run tests automatically before each commit:
After cloning the repository, set up the pre-commit hooks:
./scripts/setup-husky.sh
This ensures the test suite runs automatically whenever you create a commit, preventing commits that would break tests.