Snowflake’s Postgres mirror gives agents fresher data—but schema-level replication widens the access boundary

Snowflake has made Postgres data mirroring generally available, turning operational tables into continuously updated Snowflake tables without a separately managed CDC service. For teams grounding data agents in live application state, the important change is not merely easier ingestion: Snowflake now offers a defined freshness path, transactional guarantees and a reviewable choice over how broadly source schemas are exposed.

The agent-facing gain is a clearer freshness contract

Snowflake says each mirror maintains target tables from inserts, updates, deletes and supported schema changes. Its $live views combine materialized target data with pending change records, exposing committed source changes with approximately 30 seconds of lag even when the configured apply interval is longer. The ordinary target tables update on the apply schedule, while a seven-day $changes feed preserves recent inserts, updates and deletes for inspection. Snowflake’s documentation also says row changes from one source transaction become visible together, preserving cross-table relationships when agents join mirrored tables.

That separation gives operators a useful design choice. Latency-sensitive agent queries can read $live; workloads that prefer predictable materialization and lower apply frequency can use target tables. Snowflake bills the apply operation as a serverless task, and documents task-level cost attribution through SERVERLESS_TASK_HISTORY. Freshness is therefore observable, but it is not free or automatic: teams still need to decide which surface an agent queries and set acceptable lag and cost thresholds.

Automatic schema growth is also automatic exposure

The most consequential governance detail sits in the table-versus-schema replication choice. Table-level mirrors copy only named tables; newly created source tables remain outside the mirror until explicitly added. Schema-level mirrors automatically include every current and future table in the selected schema. Snowflake explicitly warns that this creates a larger blast radius because a new table can become visible in Snowflake without a separate mirror change.

For an agent deployment, that distinction should become a policy gate rather than a setup convenience. A schema that later receives a sensitive table could silently expand the data available downstream, even if the agent’s semantic layer and prompt configuration are unchanged. Curated table-level mirrors are the safer default for mixed or fast-changing operational schemas; schema-level mirroring fits cases where the schema itself is the approved access unit.

What operators should instrument

The GA architecture removes connector operations, not operating responsibility. Teams should monitor mirror lag, apply-task failures and per-mirror serverless cost; document whether agent queries use target tables or $live; and review source-schema additions when schema-level replication is enabled. Snowflake’s launch post says mirroring is available on AWS and Azure wherever Snowflake Postgres runs, while the documentation says mirrors cannot cross accounts, regions or cloud providers. Those boundaries simplify the topology, but the new control plane is table membership: freshness improves only if access expands deliberately.