Top 3 Open Source Postgres MCP Servers in 2026

This is a two-part series on database MCP servers:

1. Open Source Postgres MCP Servers (this one)
2. Database MCP Servers, the multi-database companion

At Bytebase we work on database access control all day, so pointing an AI agent at a real database is not a hypothetical for me. Picking a Postgres MCP server is easy right up until the database on the other end holds something you actually care about. What runs fine against a throwaway local database behaves very differently in production. That split, trusted local development vs. production, is the lens I use here. Most of these servers are great at the first and quietly dangerous at the second.

Building one safely is harder than it looks. Anthropic's own reference Postgres server got archived after people noticed its "read-only" mode happily accepted COMMIT; DROP SCHEMA public CASCADE;. Read-only, except when it wasn't. So I care less about the feature list and more about two questions: what can the agent actually do, and can you prove afterward what it did. The three servers below answer those very differently.

Postgres MCP server GitHub star history

pgconsole#

pgconsole, is the newest of the three. It is a self-hosted Postgres console, a web SQL editor first, that also hands its connections to agents over a built-in MCP endpoint. The important part: the agent never sees a connection string. It gets a token, and every call runs through the same access rules and audit log as a human clicking around the console. The agent talks to pgconsole, and pgconsole talks to the database.

Most database tools land at one of two extremes. Heavyweight platforms that need real infrastructure to stand up, or lightweight editors with no access controls at all. pgconsole sits in the awkward, useful middle: a Postgres editor with team controls built in, shipped as a single binary you run yourself.

pgconsole gives the agent its own identity, acting on behalf of a user with rights attenuated to least privilege

The access control is the heart of it, and it treats agents as first-class principals instead of bolting them on after the fact with built-in delegation and attenuation.

Key Features:

• One self-hosted binary. Connections, users, and access rules live in a versioned pgconsole.toml, GitOps-style, and you run it with npx or Docker. No separate database to babysit.
• Fine-grained, default-deny access. Seven independent rights (read, write, DDL, admin, and more), scoped per connection, with nothing allowed unless a rule grants it. pgconsole parses every statement before it runs, so a destructive query cannot sneak through a read-only tool.
• Agents as first-class identities. An agent authenticates as its own principal, or acts on behalf of a user. In delegated mode it inherits that person's permissions, capped lower and never higher, and it loses access the moment the user does.

The alice-claude agent acts for Alice, capped to read-only on a single connection:

[[agents]]
id = "alice-claude"
on_behalf_of = "alice@example.com"
permissions = ["read"]   # capped at or below Alice's own grants
connections = ["prod"]   # and scoped to a single connection

Best For: teams that want a self-hosted Postgres editor and a genuinely governed agent path (distinct identities, delegation, least-privilege caps) without standing up a whole platform.

One honest caveat: it is young. Around 120 stars, Apache-2.0, recent first releases.

Verdict: the access model is the reason to run it. Distinct agent identity, on-behalf-of delegation, and attenuation that holds an agent at or below the human it acts for, all enforced by a SQL parser rather than by trust. If you remember one design from this post, make it this one.

Supabase MCP#

Supabase MCP manages a whole Supabase project: auth, storage, edge functions, branches, not just the Postgres database underneath. That breadth is both the appeal and the cage. It only works on Supabase.

It is a first-party server from Supabase, the open-source Firebase alternative, and it inherits the company's instinct to treat everything as one managed surface. That is why it reaches well past plain SQL into auth, storage, and functions.

Supabase MCP exposes the whole project surface, but only for Supabase-hosted databases

Key Features:

• Wide surface: 29 tools across eight feature groups (Account, Database, Debugging, Development, Edge Functions, Branching, Docs, Storage), covering migrations, TypeScript type generation, and serverless functions beyond plain SQL.
• Hosted, with OAuth 2.1 and automatic token refresh, so no local server, binaries, or hardcoded credentials.
• Stronger security defaults than most: project scoping, feature-group restriction, and a dedicated read-only role (supabase_read_only_user).

Best For: teams already on Supabase who want their agent to manage the project, not just query it.

Verdict: excellent if Supabase is your platform, irrelevant otherwise. Two things to know: the default tool set is heavy (~19.3k tokens, though selective loading cuts it to ~4.2k), and the Management API endpoint behind execute_sql is still beta with no row limits. More guardrails than most. But like every server here, it mitigates prompt injection, it does not solve it.

Postgres MCP Pro#

Postgres MCP Pro, from Crystal DBA, is usually the first result when you search for a Postgres MCP server. It is host-neutral, point it at any Postgres, and it goes further than most. Where the others stop at "run this query," it brings a DBA's tuning toolkit.

Crystal DBA open-sourced it as the on-ramp to its AI-driven Postgres tooling. Then Temporal acquired the company in September 2025, and active development of the server has mostly stalled since. That matters, and I will come back to it.

Postgres MCP Pro adds tuning analysis, but defaults to unrestricted read/write access

Key Features:

• Performance analysis: index tuning, EXPLAIN plan inspection, and database health checks. This is the real differentiator.
• Two access modes: unrestricted (full read/write, arbitrary SQL) and restricted (read-only, with query-time limits).

Best For: developers and DBAs who want the agent to diagnose a slow query or propose an index, not just read rows.

Two things to weigh before reaching for it:

• It defaults to unrestricted, and every README example uses it. Out of the box the agent gets full write access and arbitrary SQL. Set --access-mode=restricted for anything past a dev sandbox. Shipping with the safety off by default is a choice I disagree with.
• Development has stalled since the acquisition. The last tagged release (v0.3.0) was May 2025, and commits trailed off after the September 2025 Temporal deal (the last one landed in January 2026). Merged work like streamable-HTTP transport never made it into a release or the Docker image, people are asking for one, and 63 issues sit open, including a connection-pool leak under SSE that is the most-reacted of the bunch.

Verdict: the tuning features are genuinely good, and still the reason to keep it around for hands-on work. But change the unrestricted default on day one, pin a known-good version, and factor in the stalled maintenance before you let it anywhere near production.

Postgres MCP Server Comparison Table#

Star counts are from the time of writing and move fast. Treat them as a rough adoption signal, not a ranking.

Summary#

None of these three is finished. pgconsole has the strongest access model (separate agent identity, on-behalf-of, attenuation) but it is the youngest. Supabase MCP is the most polished, as long as you live on Supabase. Postgres MCP Pro has the richest toolkit but lost its momentum to an acquisition. Pick by where you sit: pgconsole for a self-hosted editor with a governed agent path, Supabase if you are already on Supabase, Postgres MCP Pro to diagnose a slow query in dev (after you switch off the unrestricted default).

All three are great on a laptop and get scarier in production, for the same structural reason. Simon Willison named it the lethal trifecta: an agent with access to private data, exposure to untrusted input, and a way to send data back out. A correctly scoped credential does not save you, because the attack arrives through the prompt, not the permissions. So the real test is not "can the agent query the database." It is "what happens when the prompt tells it to do something it shouldn't."

Need more than one engine, or production data that wants column-level masking and a real change-review workflow? Then you have outgrown a single-purpose Postgres server, and that is what the companion post is about:

• Top Database MCP Servers: the multi-database companion, covering DBHub, Google MCP Toolbox, AWS, and Bytebase.
• Governed MCP vs. Raw MCP: a deeper look at the production side of agent database access.
• How to Govern AI Agent Access to Enterprise Data: identity, masking, and audit for agents.