A database failover can preserve uptime and break the answer

A PostgreSQL MCP server can remain available during failover and still return the wrong answer. The connection retries against a replica. The replica is behind. A conversation combines a pre-failover result with a post-failover follow-up. Every query succeeds, so the final answer looks complete.

Consistency Contracts

Before production, give each workflow a consistency contract:

• eventual with a disclosed lag budget
• monotonic within one conversation
• read-your-writes
• point-in-time across multiple queries
• primary-only

Making Results Traceable

Then make source identity, schema version, snapshot marker, observed time, and freshness part of material results.

Testing Beyond Promotion

Test more than promotion:

• idle pooled connections
• active transactions
• prepared statements and DNS caches
• interrupted multi-query answers
• bounded retries
• conversation continuity
• schema and policy versions
• paused replay and catch-up
• failback

Never concatenate partial rows from the old primary with rows from the new one. If the answer cannot prove one consistency boundary, discard the partial result and return a structured retryable failure.

Availability is a transport property. Trustworthy answers need a data contract.

Full test guide: MCP server for Postgres: test failover consistency, not only availability