@modelcontextprotocol/server-postgres Is Deprecated: Migration Guide

The short answer

@modelcontextprotocol/server-postgres is deprecated on npm, and its source now lives in the read-only modelcontextprotocol/servers-archived repository.

The archive states that these reference implementations are no longer maintained, receive no security updates or bug fixes, and carry no security guarantees. The npm package page labels the package deprecated and says it is no longer supported.

Do not treat deprecation as an instruction to replace one package name with another immediately. First preserve the old server's effective behavior:

• one read-only query tool
• SQL executed inside a read-only transaction
• schema resources discovered from PostgreSQL metadata
• a PostgreSQL connection string passed to a local stdio process

Then choose a maintained local server, a self-hosted remote server, a provider-specific server, or a hosted PostgreSQL MCP gateway based on the actual workflow.

Current status of the PostgreSQL reference server

The archived PostgreSQL source remains useful for understanding legacy configurations. The repository was archived on May 29, 2025, and its README now directs users toward maintained servers and the wider MCP ecosystem.

The distinction matters because old tutorials continue to show this pattern:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "postgresql://user:password@host:5432/database"
      ]
    }
  }
}

Finding this block in Cursor, Claude Desktop, Claude Code, VS Code, or another MCP client means the client starts a local Node.js process and supplies the database credential to it. It does not mean the configuration has automatically migrated to a maintained server.

Why migrate if the package still works?

Deprecation creates operational risk rather than an immediate protocol error. A package can remain downloadable and continue starting while becoming a poor dependency for production access.

No maintenance path

An archived repository does not accept normal fixes. Future PostgreSQL, Node.js, MCP transport, client, or dependency changes can break behavior without a supported upgrade path.

No security updates

The official archive explicitly says archived servers receive no security updates. A read-only SQL transaction reduces write risk, but it does not address dependency vulnerabilities, credential exposure, result leakage, denial of service, or mistakes in surrounding client configuration.

Credentials are distributed to client machines

The common configuration places the PostgreSQL URL in an MCP client file or passes it as a process argument. Each machine running the server becomes another place to protect, rotate, and remove the database credential.

The original scope was deliberately small

The server exposed a single read-only query tool and schema resources. That simplicity was useful as a reference implementation, but teams often now expect authentication, remote transport, per-user revocation, table-level policy, activity evidence, provider workflows, or PostgreSQL tuning.

Migration is the moment to decide which of those requirements are real rather than assuming every replacement should expose more database power.

Choose the right migration target

There is no universal replacement because the available PostgreSQL MCP servers solve different jobs.

Use the PostgreSQL MCP server comparison to evaluate current local, provider-specific, self-hosted, and hosted options. Check the selected project's repository, release history, security policy, transport, and permission model before installing it.

The official MCP reference-server repository is educational, not a complete product directory. For discovery, use the official MCP Registry and then verify the publisher and source repository independently.

How to migrate from @modelcontextprotocol/server-postgres

Step 1: inventory every old configuration

Search user, workspace, repository, container, and deployment configuration for:

@modelcontextprotocol/server-postgres

Record:

• client and configuration location
• database host and environment
• PostgreSQL role
• users who can run the client
• queries or workflows that depend on it
• whether the credential appears in a file, process argument, shell history, secret manager, or documentation

Do not remove the package from the first machine before finding the rest. A forgotten client can preserve an old credential and continue accessing the database after the visible migration appears complete.

Step 2: document the effective read-only boundary

The old reference server ran queries inside a read-only transaction. Determine whether the connected PostgreSQL role was also read-only.

These are different controls:

• the MCP server decides which tool and SQL behavior it permits
• PostgreSQL decides what the authenticated role can actually do

If the old role could write but the package prevented writes, replacing it with a more capable server can silently widen access. Create or verify a dedicated role that lacks write, DDL, ownership, replication, and administrative privileges unless the workflow explicitly requires them.

Document required schemas, tables, views, functions, and operations before selecting the replacement.

Step 3: select the replacement architecture

Choose local, self-hosted remote, provider-hosted, or managed gateway deployment intentionally.

A local server keeps transport simple but leaves package execution and credentials on every client machine. A self-hosted remote server centralizes deployment but adds TLS, authentication, authorization, updates, logs, and availability to your operational responsibilities. A provider server is appropriate when the agent needs platform controls. A hosted gateway can centralize credentials and distribute revocable client access.

Reject candidates that cannot reproduce the required permission boundary or the client's supported MCP transport and authentication flow.

Step 4: deploy with a new credential

Do not reuse the exposed legacy connection string by default. Create a new PostgreSQL credential for the replacement and grant only the documented access.

For a local server, place the credential in the client's supported secret or environment mechanism instead of committing it to a repository. For a remote server, store the database credential server-side and require the AI client to authenticate separately.

Keep development, staging, and production identities separate. A recognizable role name such as mcp_analytics_readonly makes database logs and revocation easier to understand.

Step 5: migrate one client and test behavior

Update one low-risk client first. Verify:

1. server initialization and tool discovery
2. schema access for required objects
3. one small read-only query
4. row and result-size handling
5. one forbidden table or schema
6. one attempted write that must fail
7. authentication revocation
8. expected database or MCP activity evidence

A successful SELECT 1 proves connectivity, not authorization. The denied tests show whether the migration preserved the old boundary.

Use the current client-specific guide for configuration details: Cursor MCP setup, Claude Code MCP setup, VS Code MCP setup, or ChatGPT MCP setup.

Step 6: rotate the old PostgreSQL credential

After every intended client uses the replacement:

1. disable or rotate the old database password
2. confirm old configurations can no longer connect
3. remove the package block from user and workspace files
4. clear copied connection strings from secret stores and deployment variables
5. remove credentials from documentation and onboarding examples
6. investigate any client that still attempts to authenticate

If a connection string was committed to Git, deleting the current line is not enough. Rotate the credential immediately and follow the repository's secret-remediation process for history and forks.

Step 7: define ownership and updates

Record who owns:

• server or gateway updates
• PostgreSQL role reviews
• client access and offboarding
• credential rotation
• denial tests
• activity retention and incident evidence

Pin and review local or self-hosted versions. For a managed service, review product changes and the provider's current security and availability documentation. Re-run access tests when tools, schemas, roles, or client permissions change.

Migrating to a hosted PostgreSQL MCP link with datamcp

Full disclosure: datamcp is our product.

datamcp connects to PostgreSQL 12+ and publishes a remote MCP endpoint. The PostgreSQL credential remains on the hosted connection instead of being copied into each AI client's local package configuration.

The migration path is:

1. create a dedicated PostgreSQL role
2. add the PostgreSQL connection to datamcp
3. create a Read Only MCP link for the first test
4. authenticate the client with a datamcp API key or OAuth 2.0 with PKCE
5. verify schema inspection and one small query
6. test a denied write and an excluded table
7. review PostgreSQL query activity and denied operations
8. rotate the credential used by the archived local package

Each PostgreSQL MCP link can use Read Only, Read, Write & Delete, Full Access, or Custom table-level operations. The effective PostgreSQL role remains a separate boundary, so a link cannot create a database privilege the role does not have.

datamcp is not a replacement when the requirement is local-only operation, multi-database support, provider administration, or automated index tuning. Use the hosted PostgreSQL MCP page to evaluate the managed path and the comparison guide for alternatives.

Migration mistakes to avoid

Replacing the package without changing the role

A replacement with write tools can turn an overprivileged PostgreSQL role into real write access. Restrict the role before changing the MCP layer.

Assuming “read-only” means “non-sensitive”

Read-only access can still expose customer records, credentials stored in tables, internal prompts, or large datasets. Restrict schemas, tables, rows, and returned fields at the database or application layer.

Copying the old connection string into a new repository file

Changing the package while preserving plaintext credential distribution does not solve the credential problem. Use client secret inputs, environment management, or a remote server with separate client authentication.

Migrating every client at once

Move one client, test it, and observe denials before scaling the change. A staged migration makes transport, tool-schema, and permission differences easier to isolate.

Forgetting revocation

Migration is incomplete until the old credential fails. Confirm denial from an old client after rotation rather than assuming configuration cleanup removed every copy.

Deprecated PostgreSQL MCP server FAQ

Is @modelcontextprotocol/server-postgres deprecated?

Yes. npm marks the package deprecated and unsupported. Its source is stored in the archived Model Context Protocol reference-server repository, which states that archived servers receive no security updates or bug fixes.

What replaced @modelcontextprotocol/server-postgres?

There is no single official drop-in replacement. Choose a maintained server based on whether you need local queries, PostgreSQL tuning, Supabase or Neon administration, self-hosted remote access, or a managed PostgreSQL MCP endpoint.

Is it safe to keep using version 0.6.2?

An existing installation may continue running, but the package is unsupported and archived. For production or sensitive data, plan a migration rather than treating current runtime success as evidence of maintenance or security coverage.

Was the old server read-only?

Its query tool executed SQL inside a read-only transaction. During migration, also use a dedicated read-only PostgreSQL role so the database remains the final enforcement layer.

Should I rotate my PostgreSQL password?

Yes, after migrating every intended client. Rotate immediately if the connection string was committed, broadly shared, or placed in an insecure client configuration.

How do I find maintained PostgreSQL MCP servers?

Start with the official MCP Registry, then verify the publisher, repository activity, releases, transport, security policy, and permission behavior. Use the PostgreSQL MCP comparison for a use-case-based shortlist.

For the next step, compare hosted and local MCP servers, review the production MCP security checklist, or create one read-only PostgreSQL link on the Free plan.