Workday and Snowflake call the link zero-copy—but one access path still materializes data
The GA integration offers two materially different freshness models. Teams should choose between scheduled Workday Data Lake refreshes and live tenant queries before promising agents current data.
Snowflake and Workday have made their bidirectional Data Cloud integration generally available, but “zero-copy” does not describe one uniform runtime. The companies’ own architecture splits Snowflake-side access into a scheduled materialization path and a live-query path, with different freshness and workload implications. Snowflake’s launch post is unusually explicit about that distinction.
Two routes into Snowflake
Customers connect a Workday tenant, mount the Workday Data Cloud catalog as a catalog-linked database and query its tables from an existing Snowflake account. The first route, Workday Data Lake, materializes selected catalog objects on a customer-defined refresh schedule. Snowflake positions that route for reporting, analytics and model training where near-real-time freshness is unnecessary. The second, Workday Live Data Query, runs against the live Workday tenant over standard SQL through JDBC or Python drivers and applies the access rules that govern the requesting user in Workday. Snowflake positions that path for operational dashboards and agents that need data measured in minutes. Source: Snowflake.
That choice matters more than the umbrella label. An agent using a periodically materialized object can still reason over data that changed after the last refresh; an agent using Live Data Query instead puts the operational dependency on the Workday tenant and its live authorization path. The launch does not publish comparative latency, throughput, concurrency or failure-behavior measurements for the two routes, so buyers cannot infer that the live path should replace the scheduled one for every workload. Source: Snowflake.
The reverse direction is different again
For Snowflake-to-Workday access, Workday Prism Data Management exposes Snowflake tables as external tables. Snowflake says those tables appear inside Workday and can be joined with HR and financial records without ETL or duplication. Its example combines sales-performance data from Snowflake with worker data so a Workday agent can identify employees who may need support, recommend training and assign it. Source: Snowflake.
The availability boundary is also concrete. The integration is available on AWS and Google Cloud, and Workday customers whose tenants run on Public Cloud can use it now. Private Cloud customers must discuss an expedited move with their Workday account teams. The initial Snowflake-facing objects include Worker, Position and Payroll data; “money data” is described as coming later. Source: Snowflake.
The practical deployment question is therefore not simply whether to enable zero-copy integration. It is which direction, freshness model and authorization boundary each agent should use—and what happens when its chosen path is stale or unavailable.
sources
comments · 0