Snowflake Postgres mirroring makes fresh operational data easier—but data agents still need an explicit consistency contract

Snowflake has made Data Mirroring for Snowflake Postgres generally available on AWS and Azure. The service continuously replicates inserts, updates, deletes and schema changes into Snowflake without a separate connector or batch pipeline, according to the GA announcement.

For teams grounding analytics agents in operational data, the important detail is not simply that replication is managed. Snowflake exposes three different data surfaces, each with a different freshness and audit contract.

Pick the surface deliberately

The materialized target table is updated by a scheduled serverless apply task. Snowflake says the apply interval is configurable: a longer interval can lower compute cost by combining more changes, but it also increases the gap between a source commit and visibility in that target table.

A companion $live view overlays pending change-log entries on the materialized target and is designed to expose committed source changes with roughly 30 seconds of lag. A $changes table retains inserts, updates and deletes for seven days. Those behaviors are documented in Snowflake’s mirroring architecture guide.

That gives an agent team a practical choice:

• Use the target table when predictable materialization and simpler query behavior matter more than the lowest lag.
• Use $live when a user expects near-current operational state, and test the added query path under realistic concurrency.
• Use $changes for explanations such as “what changed?” or for an audit trail, rather than treating it as the current-state table.

The agent’s semantic layer should name that choice. “Orders” is ambiguous if one tool points at the target table while another silently uses $live.

Freshness is not the only boundary

Snowflake applies row changes from each source transaction together, preserving cross-table invariants such as foreign-key relationships. If an apply fails, it rolls back and resumes from the same metalog position. Schema changes, however, auto-commit in Snowflake and create a boundary inside a batch.

Scope can also expand automatically. With schema-level replication, a newly created Postgres table is mirrored without another mirror change. Snowflake explicitly warns that this has a larger blast radius than table-level replication, where only named tables are included. For an agent, automatic schema growth can become automatic discoverability unless cataloging and grants are reviewed separately.

The rollout checklist is therefore short but consequential: record which surface each agent tool queries; measure source-to-answer lag; alert on mirror health; prefer table-level scope for sensitive mixed schemas; and regression-test schema changes against prompts, semantic definitions and permissions.

Managed CDC removes infrastructure. It does not remove the need to define what “current,” “consistent” and “in scope” mean for an answer.