Builder Guide

Snowflake analytics sync (tenant-operated)

Each tenant can ship their own logging history into their own Snowflake warehouse — their data, their warehouse, their analytics.

The logging system captures a tenant's complete history — every request, every change, every access. That history belongs to the tenant, and the Snowflake sync exists so they can use it at warehouse scale: a tenant workspace connects a Snowflake warehouse and ships its own logging data into it, where their team runs the analytics they want — dashboards, BI tools, SQL over months of history — without putting analytical load on the live application.

Who operates it — and who deliberately can't

This is a tenant-operated feature, and the boundary is the point:

• The tenant connects the warehouse, chooses to run the sync, and receives only their own workspace's data. What lands in their Snowflake account is theirs, in their infrastructure, under their control.
• The builder does not get a warehouse view of tenant data. There is no builder-side switch that exports tenants' history for aggregate analysis — a tenant's operational and audit history is the tenant's to analyze, not raw material for whoever built the app. Builders enable and support the capability; they don't consume its output.

Why the logs export so cleanly

The highest-volume log tables are stored analytics-grade from the moment they're written — columnar, heavily compressed, shaped for exactly the time-range scans a warehouse workload wants. Combined with the append-only nature of the logging system, export is naturally incremental: history never changes behind the sync, so each run only ever has new rows to move. There is no “re-sync because something was edited” — edits don't exist in an append-only store.

How a sync run works

1. On its schedule, the sync selects the workspace's log rows that have accumulated since the last successful run for each target table.
2. Rows are transferred into the corresponding table in the tenant's Snowflake warehouse.
3. The run is recorded — in the logging system itself — scoped to that workspace, with the direction, the target table, the number of rows transferred, and whether it succeeded.
4. On failure, the error is captured and nothing advances: the next run resumes from the last successful point, so a failed sync means delayed data, never missing data.

The sync is accountable to the same standard as everything else

A pipeline that moves audit data had better be auditable itself, and this one is. Every run — success or failure — is a permanent, per-workspace entry in the logs database, queryable by time. A tenant can always answer exactly what left the platform, when, to which table, and how much. Monitoring the sync is reading its log, the same as any other.

What tenants do with it

• Long-horizon reporting — trends over quarters and years, including data that has aged past its online retention window in the operational logs.
• Their own BI stack — anything that speaks Snowflake speaks to this data: dashboards, notebooks, scheduled reports, their analysts' tooling of choice.
• Compliance archiving — paired with archive-before-delete retention, the warehouse becomes the tenant's long-term home for history the operational store no longer needs to keep online.

What builders should know

• Position it as part of the data-ownership story alongside backup/export — it answers the “can we get our data out?” question before enterprise-minded tenants ask it.
• Support questions about the sync are answered from the sync's own log: the per-run row counts and error messages are the diagnostic surface.
• Builder analytics needs are served by builder-plane data — your own account's audit log, usage metrics, and billing data — never by reaching into tenant history.

Capability review: 2026-09-14. For exact current technical availability, use the generated API Map and first-class module inventory.