Skip to content

Snowflake World Tour hits your city

See how leading teams deploy agents at scale. Find a stop near you. Register free.

Register now

HA Terminology

Before diving into how managed Postgres handles high availability, it helps to understand the key terms.

RPO (Recovery Point Objective) — How much data loss is acceptable. An RPO of zero means you cannot lose a single committed transaction. An RPO of 5 minutes means you can tolerate losing the last 5 minutes of writes.

RTO (Recovery Time Objective) — How long your application can be down. An RTO of 30 seconds means users might notice a brief hiccup. An RTO of 30 minutes means customers are waiting.

HA vs DR:

  • High Availability (HA): Quick, automatic recovery from common failures — a crashed process, a failed disk, a network blip. Usually same-region.
  • Disaster Recovery (DR): Surviving catastrophic events — an entire data center goes offline or a region becomes unavailable. Usually cross-region.

Failover — The process of promoting a standby replica to become the new primary when the original primary is unavailable.

Switchover — A planned, graceful transfer of the primary role to another node, typically for maintenance.

Replication lag — The delay between a transaction committing on the primary and being applied on the standby. Lower lag means less potential data loss during failover.

How Managed Postgres Delivers HA

When you run Postgres yourself, high availability is something you build: you configure streaming replication, deploy failover tooling, set up health checks, and wire up connection routing. With a managed service, all of that is handled for you.

A typical managed HA architecture looks like this:

┌────────────────────────────────────────────────────────┐
│  Managed Platform                                      │
│                                                        │
│  ┌──────────┐    replication    ┌──────────┐          │
│  │ Primary  │ ───────────────▶  │ Standby  │          │
│  │ (R/W)    │                   │ (hidden) │          │
│  └──────────┘                   └──────────┘          │
│       ▲                                               │
│       │  health monitoring, automatic failover        │
│       │  connection routing                           │
└───────┼───────────────────────────────────────────────┘
        │
   Your application connects here

The platform continuously:

  • Replicates data — WAL records stream from the primary to one or more standbys in near real-time.
  • Monitors health — Checks instance health, replication status, disk, CPU, and network.
  • Fails over automatically — If the primary becomes unavailable, a standby is promoted without manual intervention.
  • Routes connections — After failover, your connection endpoint resolves to the new primary transparently.

Why You Can't See or Connect to the Standby

On most managed platforms, the HA standby replicas are hidden from customers. You won't find a connection string for them or be able to query them directly. This is intentional:

  • Failover must be instant and reliable. If customer workloads are running on the standby (heavy analytics queries, long-running transactions), promoting it becomes risky. The platform keeps the standby dedicated to one job: being ready to take over.
  • Replication must stay current. Customer queries on the standby could cause it to fall behind on WAL replay, increasing your effective RPO. A hidden standby replays WAL as fast as it arrives.
  • The platform controls the configuration. Managed services guarantee specific RTO/RPO targets. Allowing arbitrary access to HA replicas would make those guarantees harder to keep.

This is different from read replicas, which some platforms offer as a separate feature. Read replicas are visible, connectable, and designed for offloading read traffic — but they serve a different purpose than HA standbys.

What Happens During a Failover

Here's the typical sequence when a primary fails on a managed platform:

  1. Detection — The platform's health monitoring detects the primary is unresponsive (usually within seconds).
  2. Promotion — The standby is promoted to primary. It finishes replaying any remaining WAL and starts accepting writes.
  3. Routing — The connection endpoint (DNS or internal routing) is updated to point to the new primary.
  4. Reconnection — Your application's next connection attempt reaches the new primary.

The entire process typically completes in under 30 seconds. During this window, active connections are dropped and new connections may fail briefly.

Planned Maintenance

Upgrades and patches use a switchover — a graceful handoff rather than a crash-triggered failover. The platform drains connections from the current primary, promotes the standby, and reroutes traffic. This results in only a few seconds of unavailability, often less than a failover.

What You're Responsible For

The platform handles replication, monitoring, and failover. But your application still needs to handle the brief interruption gracefully.

Connection Retry Logic

During failover, active connections are dropped. Your application should retry rather than immediately surfacing errors to users:

import psycopg
import time

def get_connection(dsn, max_retries=3, base_delay=1):
    for attempt in range(max_retries):
        try:
            return psycopg.connect(dsn, connect_timeout=5)
        except psycopg.OperationalError:
            if attempt < max_retries - 1:
                time.sleep(base_delay * (2 ** attempt))
            else:
                raise

Most connection pools and frameworks have built-in retry support. Make sure it's enabled and configured with reasonable timeouts.

Idempotent Writes

If a connection drops mid-transaction, you won't know whether the transaction committed. Design write operations to be safely retryable:

  • Use INSERT ... ON CONFLICT for upserts
  • Include unique request IDs to detect duplicate submissions
  • Wrap critical multi-step operations in explicit transactions

Appropriate Timeouts

Set connect_timeout and statement_timeout so your application doesn't hang indefinitely waiting for a connection to a failed node:

postgresql://user:pass@managed-endpoint:5432/mydb?connect_timeout=5&statement_timeout=30000

Conclusion

With managed Postgres, high availability isn't something you build — it's something the platform provides. Replication, health monitoring, failure detection, and automatic failover all happen without your intervention. Your job is to design applications that handle brief connection interruptions gracefully: retry logic, idempotent writes, and sensible timeouts.

Related Resources

Snowflake Postgres — High Availability

Enable and manage HA for Snowflake Postgres instances.

PostgreSQL Documentation — High Availability

Official docs covering replication concepts and standby server architecture.

Snowflake Postgres — Replication Guide

Understand how streaming replication works within Snowflake Postgres.

Updated 2026-07-08

This content is provided as is, and is not maintained on an ongoing basis. It may be out of date with current Snowflake instances