Warehouse-native marketing has taught the industry to treat every copy of customer data as a defect. That instinct is right for audiences and wrong for the moment when an app is open, a trigger has fired and the engagement platform has a few hundred milliseconds to decide what to show.
For the past three years the strongest argument in customer data architecture has been against unnecessary copies. The packaged CDP asked companies to replicate their customer data into a proprietary store, which added synchronisation delay, duplicated storage and created a second definition of the customer. Composable patterns, reverse ETL and zero-copy data sharing corrected that by putting the warehouse back at the centre, and I made the case for that correction in Zero-Copy Engagement: When the Warehouse Becomes the Campaign Brain.
The correction holds for analytical work and scheduled marketing. Computing thirty-day purchase frequency, scoring churn propensity or assembling next week’s audience inside Snowflake, Databricks or BigQuery is cleaner than copying those attributes through intermediate pipelines, and the governance benefit is real. The argument becomes dogma when a team concludes that because the warehouse can define the audience, it should also answer every question the engagement runtime asks while a customer is waiting. Building an audience and serving a decision look similar on an architecture slide, and they place very different demands on the database underneath.
Audience definition and runtime decisions are different workloads
An outbound audience is built on a schedule, and its latency is measured in minutes or hours. A job scans transaction history, evaluates segment rules and produces a list of customer keys, and whether that takes forty seconds or four minutes makes no difference to the campaign. The warehouse is doing exactly what columnar engines are built for, scanning large volumes of compressed data in parallel.
A runtime decision has a different shape. A customer opens the app, browses three categories, adds something to the cart and leaves, and the engagement platform has to decide whether to send a push, what to recommend and whether a discount applies. Before it can act it needs the customer’s current state: identity, eligibility, frequency counters, perhaps a score. If each of those answers requires a live query against an analytical warehouse, the request has to wait for compute to be available, run a lookup for a single customer and return, and a response time that would be excellent for a report becomes a missed moment for an in-app message or a web banner that is rendering now.
Figure 1. The same warehouse can define the audience and still be the wrong place to serve the decision.
The latency budget for the whole chain, from event to message, is the subject of a companion piece, How Real-Time Is Your Real-Time? This one is about a single stage of it, the point at which the runtime asks the warehouse a question and waits.
Concurrency, cold starts and the compute bill
Latency is only half the problem, and concurrency is usually the half that hurts first. Analytical engines manage many simultaneous queries by queuing them or by adding compute, and both are reasonable answers for analytical traffic. Snowflake’s documentation on multi-cluster warehouses describes the two mechanisms plainly: when resources run short, queries wait in a queue until resources become available, and in auto-scale mode the warehouse starts additional clusters, each of which consumes credits for as long as it runs. Runtime traffic behaves differently. During a sale or a product launch, events arrive in bursts, and if each event triggers a lookup, the warehouse receives a very large number of very small queries at exactly the moment the business can least afford a delay. Either requests wait in a queue, which stretches the decision past the moment it mattered, or compute scales up to absorb them, which turns a few thousand single-row lookups into a noticeable line on the cloud bill. Warehouses that suspend when idle add a further cost to the first request after a quiet period, which has to wait for compute to resume and, in Snowflake’s case, runs without the local cache, because the cache is dropped when the warehouse is suspended.
The underlying reason is the storage design. Columnar formats are excellent for aggregating a few columns across many rows and comparatively poor at returning every column of one row quickly under heavy concurrency, which is the job key-value and row-oriented operational databases are designed for. The trade-off is well documented: in 2008 Abadi, Madden and Hachem showed that column stores outperform row stores by more than an order of magnitude on data warehouse workloads, and traced their weak point to the cost of reassembling complete rows, which is precisely what a single-customer lookup asks for. Google draws the same line between its own products, describing Bigtable as the database for the serving path and BigQuery as the one for analytics. That is also why engagement platforms keep their own operational profile and ask you to synchronise attributes into it, instead of reading the warehouse on every event: the profile store next to the runtime is what lets them evaluate rules at send time under real traffic. Braze’s own documentation separates the two modes: standard Cloud Data Ingestion copies warehouse data onto Braze profiles on a schedule, every 15 minutes by default, while CDI Segments leave the data in the warehouse and reflect it as of the last refresh. On the CDP side, Adobe’s Federated Audience Composition keeps no physical copy of the data and refreshes audiences at the frequency set in each composition. In both cases the zero-copy option serves audiences, and the copy that remains serves the runtime.
The most telling evidence comes from the warehouse vendors themselves. Snowflake announced the general availability of Hybrid Tables on AWS in November 2024, describing them as a table type for fast, high-concurrency point operations with double-digit millisecond latency, aimed at use cases such as state management and data serving. Databricks launched Lakebase, a managed Postgres service positioned as an operational database for applications and agents, in June 2025 and announced general availability on AWS in February 2026, with sync tables to keep operational and lakehouse data aligned. Both products accept the premise of this article: serving single records at runtime needs an operational tier, and the open question is whether that tier lives inside the data platform, inside the engagement platform or somewhere in between.
The architecture of governed hydration
If querying the warehouse for every runtime decision fails on latency and cost, and copying everything into a packaged CDP fails on governance, the pattern that works in production sits between the two. I call it governed hydration.
The warehouse or lakehouse remains the authoritative system for customer truth. It owns identity resolution, aggregated metrics, lifetime value, predictive scores and transaction history, and nothing downstream recalculates those definitions. What changes is how the runtime gets them. Instead of asking the warehouse on every event, the architecture pushes a small, explicitly chosen set of attributes, the ones runtime decisions actually need for personalisation, eligibility, frequency and routing, into an operational store next to the engagement runtime, and updates them through change data capture or targeted syncs when they change. Databricks’ synced tables show what that choice looks like in practice, with a one-off snapshot, triggered updates on a schedule, or continuous streaming that reaches Lakebase within seconds at the highest cost.
Figure 2. Governed hydration: the warehouse stays the authority, and the runtime reads a small projection of it that the warehouse team controls.
When the customer interacts, the engagement engine reads from its operational store and decides without touching the warehouse, and the events produced by the interaction flow back into the warehouse to update history. The word “governed” carries the weight in the name. The warehouse team decides which attributes may be hydrated, with what freshness and for which purposes, and the list is versioned like any other interface, so the runtime holds a deliberate projection of customer truth and never a competing version of it. Whether that operational store is the CEP’s own profile, a Hybrid Table, a Lakebase instance or a cache the company runs itself is an implementation choice that depends on the stack, and the CDP-CEP architecture patterns shape which of those options is available. The choice is also less stable than it looks: a Braze customer whose warehouse hydrates the Braze profile today may feel the pull to hydrate it from Data 360 once the Salesforce acquisition closes, which is the question I raised in Salesforce Buys Braze: What It Means for Your Stack.
Verdict
Zero-copy is a genuine improvement for governance, audience modelling and reporting, and treating it as a rule for every runtime decision misreads what analytical engines are built to do. Warehouses aggregate many rows over seconds and minutes, engagement runtimes serve one customer in milliseconds, and the vendors on both sides are now building products that admit the difference.
The goal is fewer copies with a reason for every one that remains: a small, governed projection of the warehouse, held next to the runtime that needs it.
Sources
Database design
- Daniel J. Abadi, Samuel R. Madden and Nabil Hachem, Column-Stores vs. Row-Stores: How Different Are They Really?, SIGMOD 2008.
- Google Cloud, Bigtable vs. BigQuery: What’s the difference?, 20 April 2021.
Warehouse behaviour under concurrent traffic
- Snowflake documentation, Multi-cluster warehouses.
- Snowflake documentation, Optimizing the warehouse cache.
Operational tiers from the data platforms
- Snowflake, Snowflake’s Unistore Unifies Transactional and Analytical Data with the General Availability of Hybrid Tables, 12 November 2024.
- Databricks, Databricks Launches Lakebase: a New Class of Operational Database for AI Apps and Agents, 11 June 2025.
- Databricks, Databricks Lakebase is now Generally Available, 3 February 2026.
- Databricks documentation, Serve lakehouse data with synced tables.
Engagement and CDP platforms
- Braze documentation, Compare persistent and zero-copy data ingestion options.
- Adobe Experience League, Federated Audience Composition: frequently asked questions.
