MCP servers that can run SQL queries
6 verified servers expose a tool that can run SQL queries against a database
Most database MCP servers come down to one tool: hand it SQL, get rows back. What changes is where the query runs (a hosted Postgres branch, a local SQLite file, an analytics column store) and how much guardrail sits in front of it before a statement reaches your data.
Below are the verified MCP servers that take raw SQL and execute it, each with the exact tool it exposes for the job.
DBHub (Postgres)
Bytebase
A universal database MCP gateway that connects agents to Postgres (and others) via a DSN.
execute_sql
One execute_sql call covers SELECTs, writes, and DDL, run with transaction support and the server's built-in safety controls rather than a raw psql pipe. Pairs with a search_objects tool for schema exploration; the default when you already run Postgres.
Supabase
Supabase (community)
Connects agents to a Supabase project: run SQL, inspect schema, read logs, and manage edge functions.
execute_sql
Runs SQL against your Supabase Postgres next to its branch, migration, and list_tables tools, so an agent can inspect the schema and query it from one server.
SQLite (DBHub)
Bytebase
Run an agent against a SQLite database file through Bytebase DBHub, a zero-dependency, token-efficient database MCP server.
execute_sql
Points at a local SQLite file, so there is no network round trip and nothing to provision. Ideal for scratch data, fixtures, or an agent reasoning over a file someone handed it.
Neon
Neon
Neon's official MCP server lets agents create projects and branches, run SQL, and drive safe schema migrations on serverless Postgres.
run_sqlrun_sql_transaction
Splits one-off statements (run_sql) from transactional batches (run_sql_transaction) and runs them on serverless Postgres branches you can create per task and throw away after.
Metabase
Cognition
A maintained Metabase MCP server from Cognition that lets an agent run questions, build dashboards, and query databases across your Metabase instance.
execute_queryexecute_query_export
Executes queries through Metabase, so the agent inherits your existing data connections and can export results rather than only streaming rows back inline.
SingleStore
SingleStore
SingleStore's official MCP server lets agents run SQL on workspaces, manage starter workspaces and Stage files, and orchestrate notebooks and jobs.
run_sql
Distributed, in-memory SQL: run_sql holds up on analytical scans over datasets that would stall a single Postgres node.
What to know
A few things decide how risky this is. Write safety varies by server: DBHub's execute_sql runs with transaction support and built-in safety controls, Neon splits writes into a run_sql_transaction you can roll back, and a bare connection will run a DROP the moment the model asks. Result size is the next trap, since a SELECT * against a wide table can swamp the context window, so favor servers that cap or paginate rows. And credential scope matters most: a server pointed at one database is a far smaller blast radius than one holding cluster-admin access.
Worth remembering: the connection itself keeps nothing. A model that maps your schema and learns which column holds the customer email loses all of it at session end, then rediscovers it next time, unless that knowledge is written down outside the database.
Questions
- Can an MCP server run write statements, or only SELECTs?
- It depends on the server and how it is configured. execute_sql tools like Postgres and SQLite will run INSERTs, UPDATEs, and DDL unless you connect with a read-only role. Neon separates transactional writes into run_sql_transaction so they can be rolled back. If you only want reads, give the server a read-only database user rather than relying on the tool to refuse.
- Which server is safest to give an AI agent?
- The one with the smallest credential scope. A SQLite server bound to one file, or a Neon server scoped to a throwaway branch, limits what a wrong query can damage far more than a server holding admin credentials for your production cluster.
- How do I stop large query results from filling the context window?
- Ask for bounded queries (a LIMIT, an aggregate, a single row by key) rather than SELECT *, and prefer servers that page results. Some, like Metabase, can export a full result set out of band instead of returning every row to the model.