Every customer data vendor sells real-time. It's on the homepage, in the demo, in the answer to question fourteen of that RFP in front of your nose. The word carries a lot of weight, yet most of that weight stays out of view.
Ask what real-time actually means once the data lives in a warehouse, and that single word splits into three separate jobs.
The first is collect: getting an event into the system at all. A click, a purchase, a page view, arriving through an SDK, a stream, or a warehouse ingest pipe.
The second is decide: turning that event into something a marketer can act on. A segment membership, a propensity score, a next best action.
The third is push: getting the resulting action back out to wherever the customer actually is, whether that's an email, an ad platform, or a live web or app surface.
Three jobs but three clocks. They rarely run at the same speed, and nothing forces a vendor to tell you which clock the "real-time" on the homepage refers to.
A platform can be genuinely fast at collecting an event and slow at pushing an action, and still print "real-time" across the whole pipeline.
That ambiguity is convenient, and it's convenient in one direction. A number that describes the fastest link in the chain looks better in a sales deck than a number that describes the slowest. So the demo shows you an event landing in the system the instant it fires, and says nothing about the forty minutes between the decision and the email that carries it.
None of this makes warehouses a bad place to keep customer data. It makes "real-time" a word worth taking apart before you pay for it.
The rest of this piece is about where the slow link usually hides, why it hides there for structural reasons rather than lazy engineering, and examples of how five vendors plus a do-it-yourself path each make a different bet about what to do with it.
Let's get started.
Why a warehouse hits a wall
Everything so far assumes the warehouse can move at the speed the marketing asks for. Mostly it can't, and the reason is baked into what a warehouse is.
A columnar store keeps each column together on disk so it can scan millions of rows across a handful of columns and hand back a sum, a join, an aggregate. That design is what makes analytics fast. It also makes the opposite job slow: pulling one customer's full profile, right now, in a single lookup. Point lookups are the thing a warehouse is worst at, and a point lookup is exactly what an in-session decision needs. That is a property of the storage design, and no amount of tuning changes it.
The published numbers tell the same story once you read them by job. Take Snowflake, since its documentation is specific and the shape repeats across the category. Collecting an event is genuinely quick: Snowpipe Streaming flushes on a one-second default, tunable down to a second or up to ten minutes. Transforming it is where the floor appears. Dynamic Tables, the managed way to keep a derived table current, carry a documented minimum target lag of one minute, and that minute is a staleness target rather than a promise about latency. You cannot tune beneath it.
Snowflake's own decision guide is blunt about the edges: if you need always-current data with no lag, use materialized views; if you need sub-minute freshness with custom logic, use streams and tasks.
Which points at the real problem. Dynamic Tables can't call a stored procedure or an external function, so pushing a decision back out of the warehouse in the moment falls to a hand-built chain of streams, tasks, and an external function calling a webhook. You own the retry logic, the credential rotation, and whatever wakes you when it breaks, which is precisely the maintenance a CDP is charging you to take off your plate.
Two more costs stay off the demo. Warehouse compute queues under concurrent load, so latency stops being predictable the moment real traffic arrives, whatever target lag you set. And a virtual warehouse auto-suspends when idle, so waking it takes real seconds, invisible in a nightly batch and fatal to a respond-in-fifty-milliseconds promise if the thing was asleep when the customer showed up.
The clearest evidence is what the vendors built to get around all this. Snowflake Hybrid Tables and Databricks Lakebase are row stores bolted onto the analytical engine specifically to do the point-lookup job it can't. They are a different storage engine sold under the same name. Databricks made the split impossible to miss this year by shipping Lakehouse//RT, a separate real-time engine, as its own product alongside the Lakehouse. When a company launches a second engine for speed, the fair reading is that the first one doesn't get there on its own.
None of this makes a warehouse a bad place to keep customer data. It is the best place we have. It is the reason the slow link almost always sits at the push step, and the reason every vendor in the next section is answering the same question:
What do you do about a warehouse that was never built to act in the moment?
How fast does the context go stale?
A one-minute floor sounds like a problem right up until you ask what you were going to do with the minute. Most of the time the honest answer is nothing. If a customer's situation holds steady for the rest of the day, a segment that refreshes every ten minutes is exactly as fresh as the decision requires. The floor from the last section only bites when the context underneath it is moving faster than the warehouse can keep up.
That distinction has been drawn well before now, and the person who drew it clearest for a data audience is Martin Kihn.
In a 2023 piece, he separated real-time data from real-time action, and pointed out that acting seconds, minutes, or hours later is often the correct move rather than a compromise forced on you by slow plumbing. His example was an airline changing your seat:
The airline holds that context for hours, so the right moment to tell you is the next time you open the app, well after the change actually posts.
He is worth crediting for the framing and worth being accurate about. The phrase right-time was already circulating years earlier, in trade press and analytics writing around 2014. Kihn didn't coin it. He put it in front of the CDP crowd at the moment the category needed to hear it.
Martin Kihn
The reframe that follows is the part I want to discuss. The skill is matching what you spend on latency to how fast the customer's context actually decays, which has surprisingly little to do with buying the fastest pipeline on offer. Get it wrong in the expensive direction and you pay for speed the use case never needed, every month, on the compute bill. That is the core of what I've been calling compute-bait economics: the number on the homepage is tuned to sell, and once you hold it against a real decay rate, most of it turns out to be speed you never cash in. [LINK: compute-bait economics piece — confirm slug]
A cart abandonment makes the shape concrete. The abandon event lands in the warehouse within seconds. The reverse-ETL sync that carries the resulting audience to your email tool runs on a schedule, and on RudderStack that schedule floors at five minutes, with most syncs completing in a couple of minutes once they fire. Add the email tool's own send lag, and the message chasing the cart goes out several minutes to the better part of an hour after the person left, depending where their sync fell in the cycle. For a next-day winback, invisible. For someone still holding their phone, the moment closed before the pipeline moved.
Scott Brinker gave this a more structured shape than a single cut between real-time and right-time. In the State of Martech 2026 report, he and Frans Riemersma lay out a pace layer context stack:
Six layers of customer context, each with its own natural speed.
Market context moves over years, company context over quarters, relationship context over months, journey context over days, session context over minutes, and moment context over seconds.
The exact boundaries matter less than the consequence.
A stack that forces all six layers to refresh at moment-speed is paying six times over for freshness five of them can't use.
The idea that different layers of a system should change at different rates is older than the framing. Stewart Brand described it for buildings, and Gartner applied the same logic to enterprise software years before this report. What's current is naming the six marketing speeds and noticing that AI agents are compressing all of them at once.
Matthew Niederberger
Kihn and Brinker are answering the same question from two distances:
How fast should each decision move?
Neither settles where the work to hit those speeds should actually live. That is the next question, and it has a good model behind it.
Where the work lives
The last two sections were about how fast each decision needs to move.
The next question is where the work to hit those speeds should sit, and David Chan, at Deloitte, has spent the last few years building the clearest answer I've read.
He calls it the Dual Zone model.
The split is straightforward.
Zone 1 is the data zone: the warehouse, identity resolution, enrichment, and the historical and propensity scoring that needs large-scale data and real compute. This is macro decisioning, and it runs on whatever cadence the warehouse can support, which section two put at minutes on a good day.
Zone 2 is the engagement zone: journey orchestration, personalization, and campaign activation, the work that has to answer in the moment. This is edge decisioning, and it runs on whatever is cached and contextual right now, informed by the scores Zone 1 handed over earlier.
Chan is careful to separate this from a vague "hybrid", a label he has pushed back on directly. The model is about how the work gets distributed, who does it and where it gets done, rather than two products blended into a mushy middle.
Framed that way, a CDP is less a piece of software you buy than a set of capabilities you place, some in the warehouse and some at the edge.
The reason this matters beyond vocabulary is that the line between the two zones tends to fall exactly where your organization is already split. Zone 1 is the data team's world, Zone 2 is the marketing team's, and a CDP Institute round table tied that directly to Conway's Law, the old observation that systems end up shaped like the communication structure of the group that built them.
Your architecture mirrors your organization chart whether you meant it to or not, which is why vendors keep landing on this same two-zone shape on their own.
They are selling to a seam that already runs through the customer.
Matthew Niederberger
That sets up the rest of the piece, because every product in the next section is a different bet about that seam. Some run a light Zone 2 cache alongside the warehouse and leave Zone 1 where it sits. Some ship Zone 1 and Zone 2 as two separate products and let you wire them together. One tries to collapse both zones into a single deployment inside the warehouse itself. The latency number each one advertises is downstream of that choice, and the choice is the thing worth considering.
Five bets on the same line
The useful way to read this market is to stop sorting by speed and start sorting by where each product draws the Zone 1 and Zone 2 line, because the latency number falls out of that choice.
I've ordered them from the ones that keep the zones farthest apart to the one that sells you the whole spectrum. Each is introduced by what it actually is, since the Snowflake Native App wrapper several of them offer is a deployment option, not the product.
RudderStack: keep the two jobs apart
RudderStack is a warehouse-native pipeline company, and its reverse-ETL product states the principle plainly in its own docs:
Reverse ETL does not support ingesting streaming data.
Real-time is a separate product, Event Stream, that skips the warehouse entirely. In Dual Zone terms RudderStack refuses to blur the line: Zone 1 work runs on warehouse time, Zone 2 work runs on a separate real-time path, and the refusal to pretend otherwise is the selling point.
Reverse-ETL syncs land in a couple of minutes on a five-minute floor, billed per destination.
Hightouch: mostly in the warehouse, one admitted exception
Hightouch built its name on a zero-copy promise: query the warehouse directly, keep no shadow database, leave Zone 1 where it is. Same-session personalization is where that gets complicated, and to their credit they say so.
To blend live events with full warehouse history and answer in under a second, Hightouch caches state in an architecture that runs parallel to the warehouse, which the CDP Institute called bending the company's own no-copy rule.
Co-CEO Tejas Manohar put the target at "the amount of time it takes to press the lever on a toaster." That parallel cache is a small, explicit Zone 2 on a warehouse-first design, and the admission is what makes it credible.
Tealium: two real products, one per zone
Tealium's core is AudienceStream, a real-time CDP that has triggered on live events for years without a warehouse underneath it, a fully-formed Zone 2.
Its newer Snowflake Native App, Audience Discovery, adds a real Zone 1: you build and govern the segment definition inside Snowflake, by point-and-click, SQL, or Cortex, and the rows never leave. Activation runs through the same real-time layer either way.
Tealium is the cleanest picture of the split as two literal products, one in each zone, which is roughly how CTO Mike Anderson frames it, the data cloud as the brain and Tealium as the nervous system.
Its Context API returns a full profile in about sixty milliseconds.
Zeotap: collapse both zones into the account
Zeotap is a composable CDP that runs warehouse-agnostic across Snowflake, BigQuery, and Databricks: an SDK collects events, and a real-time orchestration layer pushes to destinations by webhook.
On Snowflake it goes further than a connector. Deployed as a Native App on Snowpark Container Services, the whole platform runs as a container inside the customer's own account, so data never leaves the governed environment and the processing cost lands on the Snowflake bill instead of a separate invoice.
Collapsing both zones into one deployment raises the honest question section two set up:
If the orchestration runs on a warehouse-speed engine, what is it caching to feel sub-second?
The constraints don't lift because the container is local, and there is no published latency SLA.
Treasure AI: buy the whole spectrum
Treasure AI, renamed from Treasure Data in April 2026, sells the whole line rather than a single point. In Composable Mode it runs zero-copy federated queries against your warehouse, with data staying put until activation.
In Complete Mode it ingests the data into its own infrastructure, where native messaging and deeper AI decisioning live. The part worth paying attention to, which Treasure says itself, is that even in Composable Mode the sub-second activation runs off Treasure's own real-time profile cache outside the warehouse, the same move as Hightouch's parallel cache, packaged as one end of a continuum.
This is a legitimate strategy rather than a bait-and-switch: one vendor, predictable pricing, a real on-ramp for enterprises that will likely want native messaging and full AI decisioning eventually. The honest understanding is that Composable Mode is an entry point with a gravitational pull toward Complete Mode, a real dependency to weigh against RudderStack at the far end, which never offers the on-ramp at all.
One disclosure: Treasure also runs cdp.com, the "independent" CDP glossary many buyers read first, so its view of the category travels further than its product pages.
I picked these five because between them they cover most of the ways the market answers the question. They are not the whole list. A handful of others are worth a shorter look, some narrower in scope, some whose direction is still settling.
A shorter look at the rest
ActionIQ answers the question much the way Zeotap does, pushing queries down against the warehouse with a separate real-time stream for triggers, and the architecture is sound.
The company around it is the part to track. Uniphore bought ActionIQ in late 2024 and folded it into a product now called CDP Agent, which is why the ActionIQ name dropped off Gartner's 2026 Magic Quadrant. That drop is easy to overlook, because Uniphore entered the same quadrant as a new Leader on ActionIQ's engine, so the technology was promoted rather than shelved. Worth a look once the roadmap under new ownership firms up.
Amperity spent years as an identity-resolution specialist with little activation of its own, and moved in May 2026, shipping Real-Time Tables for live ingestion and Real-Time Activation for in-session moments like cart abandonment at its Amplify conference. It is new and not yet independently benchmarked, so it sits on a watch list rather than a shortlist for now.
Databricks CustomerLake is the platform-draws-the-line-for-you bookend, launched in June 2026 as an agentic CDP embedded in the Lakehouse. Databricks describes a real-time serving layer for customer attributes, and two facts from Databricks itself temper that:
CustomerLake is in private preview, and the company shipped Lakehouse//RT as a separate real-time engine at the same summit.
When the real-time performance ships as its own product, the platform's real-time language is running ahead of what's wired together.
Matthew Niederberger
Snowflake, on its own is the draw-the-line-yourself option, and it is the chain the vendors above are selling you out of:
Snowpipe Streaming to ingest, Dynamic Tables to transform, and Streams, Tasks, and a hand-built external function to push a decision out.
As I have said before, you own the retry logic and the on-call that come with it. Worth it for a narrow, well-defined use case with a data team that has the room, and rarely worth it beyond that.
Census earns a line as a marker of where the category is going. Fivetran acquired it in 2025, so another independent reverse-ETL name now sits inside a larger platform.
What you're actually choosing
Step back from the five vendors and the footnotes, and the whole thing reduces to two questions.
- How fast does this decision's context decay?
- Where should the work to beat that clock sit, in the warehouse or in a layer beside it?
Every product here has answered the second question for you, and the latency number on its homepage is that answer made visible.
Buy the boundary that matches how fast your context decays, and the latency number takes care of itself.
Most marketing decisions are not moment decisions.
Relationship, journey, and company context hold for days or longer, and a warehouse serves them on its own cadence without help.
The few that genuinely turn over inside a session are the ones that justify a cache beside the warehouse or a live layer fed by it, and paying for that speed everywhere else is how the compute bill outgrows the value it returns.
So the choice is less about which vendor is fastest and more about knowing which of your decisions actually live in the bottom two layers of the context stack, then buying only as much boundary-crossing speed as those few decisions need.
If you want a structured way to lay out your own stack and see where these lines fall, that is what I built the Martech Stack Builder for. The vendors will keep selling speed. Knowing how much of it you actually need is the part they can't do for you.
Do you have any questions after reading this article?
Or need support with your Martech projects?
Discussion