Best MCP Servers for SQL & Databases (2026)

The best MCP servers for SQL and databases fall into two camps: thin query servers that run SQL and read schema (add one of these), and platform servers that manage a whole database-as-a-service. For most engineers the right answer is a single, token-light query server — DBHub or MCP Alchemy — plus read-only mode turned on. Everything past that is either a specialized need or a way to blow your tool budget.

This is the grounded shortlist: what each server does, the trade-offs, and what to skip. Every server here is real and linked, and I've kept the config notes minimal and correct. If you only want the headline: pick by which database you run and whether you need writes, not by star count.

The shortlist at a glance

Start from your database engine and your risk tolerance, then pick one server. The table below maps each to its job so you don't install three overlapping ones.

Server	Best for	Databases	Transport	Official
DBHub	Token-light SQL + schema, multi-DB	Postgres, MySQL, MariaDB, SQL Server, SQLite	stdio / HTTP	Community (Bytebase)
MCP Alchemy	Anything with a SQLAlchemy driver	Postgres, MySQL, SQLite, Oracle, MS SQL	stdio	Community
Multi Database MCP Server	Several DBs at once + TimescaleDB	MySQL, Postgres, SQLite, Oracle, TimescaleDB	stdio	Community
CentralMind Gateway	A hardened, PII-redacted API layer	Structured DBs (schema-discovered)	stdio / SSE	—
Supabase MCP Server	Managing a Supabase project	Postgres (Supabase)	HTTP (OAuth)	Official
Query | Supabase	Supabase with strict write gating	Postgres (Supabase)	stdio	Community

Nearly every option here runs locally over stdio, which is the norm — roughly 90% of MCP servers do. That keeps latency low and your queries off a third party's logs.

The default pick: one thin query server

For plain "let the agent query my database," install DBHub and stop there. It's a zero-dependency server from Bytebase covering Postgres, MySQL, MariaDB, SQL Server, and SQLite, and it deliberately exposes a small tool set — execute_sql, search_objects, plus custom tools — so it stays token-efficient and doesn't crowd out your other servers. It supports read-only mode, row limiting, and query timeouts, which are exactly the guardrails you want when an LLM writes the SQL.

A minimal stdio launch is one line:

{
  "mcpServers": {
    "dbhub": {
      "command": "npx",
      "args": ["@bytebase/dbhub@latest", "--transport", "stdio",
               "--dsn", "postgres://user:pass@localhost:5432/mydb"]
    }
  }
}

One warning: DBHub's HTTP transport defaults to binding 0.0.0.0 with no client auth. If you run it over HTTP, bind to 127.0.0.1 and put it behind a proxy or firewall. Stick to stdio locally and this isn't a concern. Setup patterns for any client are in how to add an MCP server.

When your database isn't in that list: MCP Alchemy

If you run Oracle, or anything with a SQLAlchemy driver, reach for MCP Alchemy. It's a Python server that talks to Postgres, MySQL, SQLite, Oracle, and MS SQL through SQLAlchemy, and its four tools are well-shaped for how a model actually explores a schema: all_table_names, filter_table_names, schema_definitions (with primary and foreign keys), and execute_query. The foreign-key awareness is the reason I prefer it for unfamiliar schemas — the model can follow relationships instead of guessing joins.

The cost of that breadth is trust: execute_query runs arbitrary SQL against a connection string you supply. Give it a least-privilege, read-only database account and the blast radius is small. It runs via uvx, so there's nothing to install globally.

Special cases: multi-DB and a hardened gateway

Need several databases live in one session? Multi Database MCP Server connects to MySQL, Postgres, SQLite, Oracle, and TimescaleDB concurrently and generates per-database tools (query_<db_id>, execute_<db_id>, schema_<db_id>, and TimescaleDB hypertable operations). That's its strength and its catch: it can emit 13 tools across those groups, which eats into the ~40-tool budget most clients degrade past. Install it only if you genuinely query multiple databases at once — otherwise a single thin server is the better use of slots. See the coding-agents shortlist for how that budget math plays out across a real stack.

Different problem: exposing production data safely. CentralMind Gateway doesn't hand the model raw SQL. It runs a one-time discovery pass over your schema, generates a gateway.yaml where each endpoint becomes an MCP method, and adds PII redaction, row-level security, caching, and OpenTelemetry auditing on top. It's a Go binary that speaks stdio or SSE, and REST/OpenAPI too. Overkill for a local dev database; the right tool when a database sits behind compliance requirements.

For Supabase, pick by how much you trust writes

On Supabase, there are two good servers and the choice comes down to write safety. The official Supabase MCP Server is the default — it's maintained by Supabase in the supabase/mcp repo, and the recommended setup is the hosted remote at https://mcp.supabase.com/mcp with an OAuth 2.1 browser login, so you never paste an access token into a config file. It goes well beyond SQL: list_tables, execute_sql, apply_migration, deploy_edge_function, branch management, and generate_typescript_types.

Scope it every time. Append ?read_only=true&project_ref=<ref> to the URL to force read-only transactions on a single project:

https://mcp.supabase.com/mcp?read_only=true&project_ref=<your-project-ref>

The alternative, Query | Supabase MCP Server, is a community stdio server built around a three-tier safety system: it defaults to read-only, write operations require flipping into unsafe mode via a live_dangerously tool, and destructive statements need explicit two-step confirmation. Choose it if you want that confirmation gate in front of an agent that will write. It needs a free API key to run, whereas the official server's OAuth flow needs no token at all.

What to skip, and my default

Skip installing more than one query server. DBHub, MCP Alchemy, and the multi-DB server overlap heavily — running two means duplicate execute_sql-style tools competing for the same call, which reads as the model getting worse.

Skip write access you don't need. The single highest-value setting on every server here is read-only mode plus a least-privilege database user; turn both on before you connect anything to real data. Security trade-offs across servers are covered in MCP security: what actually matters.

My default: one thin query server (DBHub for the common engines, MCP Alchemy if you're on Oracle), read-only, on a least-privilege account. Add Supabase's official server only if you actually work in Supabase, and CentralMind only when production data needs a hardened layer. Browse the full ranked list at best MCP servers, or filter by what you need on the capabilities page.