Best Database MCP Servers: Postgres, MongoDB, Vector Stores

The best database MCP server is the one that matches your database, connects with a read-only role and is still maintained. BusinessMCP’s Databases page lists 19 options across relational, document, serverless and vector stores, and notably shows several older reference servers as Archived. Pick by database type first, then by label and permissions.

Pick by database type

The directory’s Databases category lists 19 servers. Grouped by what they connect to, with the labels and descriptions as the page gives them:

Type	Servers on the page	Labels shown	Described as
Relational	PostgreSQL, MySQL, SQLite	Archived, none, Archived	Queries, schema inspection
Serverless SQL	Neon, PlanetScale, Turso	Verified, none, none	Branching, edge replicas
Managed backend	Supabase	Verified	Docs, projects, databases, Edge Functions
Document	MongoDB	Verified	Documents, aggregation, Atlas management
Key-value	Redis, Upstash	Archived, Verified	Caching, pub/sub, serverless Redis and Kafka
Warehouse	BigQuery, Snowflake	none, Archived	SQL over large datasets
Search	Elasticsearch	Archived	Full-text search and analytics
ORM	Prisma	Verified	Type-safe access for Node and TypeScript
Vector	Chroma, Pinecone, Weaviate	Verified, Verified, Archived	Embeddings and semantic search
Spreadsheet-style	Airtable	Verified	Records in bases

Treat “none” as no label shown, not as a problem. Treat Archived as a prompt to look for a maintained fork or the vendor’s own server before relying on it.

Key takeaway: the label tells you whether anyone is maintaining the server. It does not tell you whether the server will respect your data. That depends on the role you connect with.

The one setup rule: read-only role

Whatever you choose, create a dedicated database role that can only read, and only the schemas you want the assistant to see. This single step removes most of the risk. A model that cannot run an UPDATE cannot run one by mistake or because text in a record told it to. Where possible point the server at a replica or a staging copy.

Setup checklist:

1. Create a role with SELECT on specific tables or views.
2. Set a statement timeout so a clumsy query cannot lock up the system.
3. Limit row counts if the server supports it.
4. Store the connection string in an environment variable or secret store, not in a shared config file.
5. Run a harmless question first, such as asking for the schema of one table.
6. Compare the answer against a query you run yourself.

Relational: Postgres, MySQL, SQLite

These are the most requested. The page shows the reference PostgreSQL and SQLite servers as Archived, so look for a maintained alternative from your cloud provider or database vendor. Neon and Supabase, both Verified there, offer their own MCP servers tied to their platforms, which also manage projects, not just queries. That wider reach is useful and also riskier, so scope tokens carefully. If you work in an editor, see Cursor MCP servers for where to put the connection string.

Document and key-value stores

MongoDB is Verified, with document operations, aggregation pipelines and Atlas management. Aggregation pipelines can be expensive, so a read-only user and a timeout matter. For Redis, the page shows the reference server as Archived and Upstash as Verified, described as serverless Redis and Kafka. Be careful with anything cache-related: flushing a cache is a write.

Warehouses

BigQuery and Snowflake servers let an assistant answer questions over large datasets. Cost is the main concern: a careless query over a big table can bill real money. Use dataset-level permissions, query cost limits where the platform offers them and require approval for any query that scans large tables. The directory does not state pricing for these servers, so check the vendors.

Vector databases for retrieval

Chroma and Pinecone are Verified, while Weaviate is shown Archived. They suit retrieval and semantic search. Remember that vector stores often hold chunks of private documents, so apply the same access thinking as for any database.

What can still go wrong

• Prompt injection through data. A row containing instructions can steer an agent that reads it. Read-only access limits the damage, and our article are MCP servers safe explains the pattern.
• Over-broad schemas. Expose views rather than raw tables where you can.
• Credential leakage. Keep strings out of repositories.
• Stale servers. Archived means no future fixes.

Where to go next

Browse every category in the BusinessMCP MCP server directory, read how its labels work in official vs verified MCP servers, and see the wider developer picture in best MCP servers for developers. Verify each server on its publisher’s page, since listings change.

Choosing between the options, quickly

If you want a short decision path rather than a catalogue, use this one.

1. You already run Postgres or MySQL. Look first for a maintained server from your database vendor or hosting provider, since the reference servers are shown as Archived on the directory page.
2. You use Supabase, Neon or MongoDB. Use the vendor-linked server and scope its token to one project.
3. You need analytics over large data. A warehouse server fits, with cost limits in place.
4. You are building retrieval. Use a vector store server and keep your document access rules in mind.
5. You are not sure. Start with SQLite or a staging copy and a read-only role.

The directory also has a Dev Tools category that overlaps, since Prisma appears in both. A server can sit in more than one place, so check the listing rather than assuming the category tells the whole story.

Questions to ask the database owner

If the data is not yours, talk to whoever owns it before connecting. Ask which tables contain personal data, whether a replica exists, what the acceptable query load is and who should be told if the assistant is connected. These conversations are quick and prevent awkward surprises later.

Before you go live: a test plan

Write five test questions with known answers, for instance a row count, the largest order last month and the columns of one table. Ask the assistant each one, then run the equivalent SQL yourself. If any answer differs, find out why before trusting the setup for anything else. Repeat the test whenever you change the server, the role or the schema. It takes ten minutes and catches silent misreads, such as a wrong date range or a join the model invented.