> ## Content Index > Fetch the complete content index at: https://www.martechtherapy.com/llms.txt > Use this file to discover other available public pages before exploring further. # What real time actually costs - URL: https://www.martechtherapy.com/what-real-time-actually-costs/ - Published: 2026-10-06T06:49:38.000Z - Updated: 2026-10-06T06:49:37.000Z - Description: Real time is several different speeds, with very different bills. What each one is for, and the cost nobody likes to mention. - Author: Matthew Niederberger SPONSORED ![CTA Image](https://storage.ghost.io/c/57/c5/57c5ffb5-ecd9-4bf6-b870-68986d981176/content/images/2026/08/Databricks_idF4fnHpaJ_14.svg) ****Sponsored by Databricks.** [Databricks](https://www.databricks.com/?ref=martechtherapy.com) commissioned and funded this guide and reviewed it before publication for factual accuracy. They did not get to change the conclusions. [Full disclosure at the foot of this post](#about-the-series). Somebody says "real time" in a meeting and the room nods. It is *the most agreeable phrase in martech*, because everybody in the room assents to something slightly different and nobody finds out until the CFO starts looking for you. I wrote about the architecture of this in July, in [real-time from a warehouse](https://www.martechtherapy.com/right-time-marketing-and-the-speed-of-context-decay/): > How quickly context goes stale, where the work should sit, and where nine different vendors draw their line. That piece is for somebody choosing a platform. This one is for somebody who already has one and has to say what they want out of it when they need it most. The two are different jobs, and the second one is where the money actually goes, and where your CFO will focus on. ## What you are actually buying Ask what real time costs and somebody gives you a compute number. Compute is the easy part to price. > **Compute**: the processing power, CPU, memory, and infrastructure used to run queries, transform data, and execute calculations What you buy when you buy speed is the obligation to be right continuously. A nightly job has a window inside it. Something breaks at two in the morning, somebody notices at seven, it gets fixed by eight, and no customer ever knows anything happened. That window is not on the architecture diagram. Nobody put it in the business case. Nobody has ever presented it to a board. And it is doing an enormous amount of quiet work. Take the window out and every correction becomes visible. An upstream failure stops being a quiet rerun and becomes an incident. A wrong segment is wrong in front of a customer instead of wrong in a table for six hours. And somebody is now on call, at night, for a marketing audience. I watched a team discover this about five weeks after go-live. They had asked for real time, they had got it, and it worked. Then a field changed upstream one evening, and because there was no longer a night in which anybody could notice, the personalisation on the site ran wrong until the first person opened a laptop the next day. Nothing about the pipeline had failed. The pipeline did exactly what it was built to do, *faster than anyone could check it*. That is the cost. It lands on people rather than on a line item, which is precisely why it does not come up in the meeting where the speed gets agreed. I have started calling it the correction window, because it needs a name before anybody will argue about it. How long you have to catch a mistake before somebody outside the company sees it. Days at the weekly end, a whole night at nightly, minutes at micro-batch, and none at all at the top. ![Bar chart of the window to catch a mistake at five data speeds, from as long as you need at weekly, to none at in-session state.](https://storage.ghost.io/c/57/c5/57c5ffb5-ecd9-4bf6-b870-68986d981176/content/images/2026/10/talking-to-data-engineering-03-what-real-time-actually-costs-fig1-correction-window-1.svg) The one-page version Five speeds, what each one is for, and the window you give up at every step. [Download the PDF ](https://www.martechtherapy.com/content/files/2026/10/talking-to-data-engineering-03-what-real-time-actually-costs.pdf) ## Speed is only worth what the slowest step allows The second thing, and the one you can act on after reading this article, or the guide. Data that arrives in two hundred milliseconds, into a process where campaign approval takes two days, has bought you *nothing at all*. You paid for the pipe. The pipe is not what was slowing you down. So before asking for anything to be faster, find out what the rest of the chain does. How often does the destination platform ingest what you send it? Plenty of them are hourly or daily whatever you feed them. How long does an approval take in your team? How often does the campaign actually go out? Then hold those numbers next to the one you were about to ask for. Paid media is the cleanest example. Somebody asks for a real-time audience sync into an ad platform that refreshes its own side once a day. The engineering is real, the bill is real, and the audience then sits in a queue for nineteen hours. Everybody did their job properly and nothing arrived any sooner. ## Five speeds, and most things live at the bottom The sheet lays 5 common speeds out: weekly or on request, nightly batch, micro-batch, streaming, and in-session state. Each one with an honest latency band, what it is genuinely for, what changes about the failure surface when you move up, and the correction window you give up to get there. Two things are worth saying in prose rather than on a card. The first is that most of what marketing runs day to day sits comfortably at the slow end: audiences, scores, reporting, and most planned campaigns. Nightly is not a compromise for these. It is usually the right answer, and it is cheap and predictable in a way the faster speeds rarely are. The second is that a handful genuinely belong at the top, and those are worth arguing for. On-site recommendations, where the screen is the decision. Fraud and payment failures. Anything that has to change what a person sees before they leave the page. The point of being disciplined about everything else is that *the budget still exists* when one of these comes along. In between those two sits the speed almost nobody asks for by name, which is the one most requests actually want. Every few minutes. Not overnight, not sub-second, just often enough that within the hour is always true. Basket recovery lives there. Session audiences live there. It usually costs a fraction of streaming, and it covers most of what people describe as needing to be real time. If you take one thing from this into your next planning meeting, that is the thing: > The answer you are looking for is usually the one nobody has a word for. ![Dumbbell chart of sixteen marketing decisions, showing the speed each is usually asked for against the speed that is usually enough. Most move to slower speeds.](https://storage.ghost.io/c/57/c5/57c5ffb5-ecd9-4bf6-b870-68986d981176/content/images/2026/10/talking-to-data-engineering-03-what-real-time-actually-costs-fig2-asked-vs-needed-1.svg) ## The one everybody gets wrong Abandoned basket. It is the example people reach for when they want to justify streaming, and it is almost never a streaming problem. The email lands in an inbox. The person opens it when they open it. Within the hour is indistinguishable, from where they are sitting, from within the second. What people mean is that it feels urgent, and they are not wrong that a basket cools. But it cools over hours, not milliseconds, and those are two different speeds with two different bills. There is one part that does have to move quickly, and it is not the email. It is the purchase that should cancel it. A basket reminder that lands after somebody has already bought is the one customers tend to complain about, so the order has to reach whatever decides the send at least as fast as the send itself. That is a smaller and cheaper thing to ask for than streaming the basket, and it is the one worth asking about. So the sheet has one question on it before anything else. > What happens if this is an hour late? For abandoned basket, honestly, very little. Try it on your own list and see how often the answer comes back "nothing anybody would notice". That is the answer that saves money, and in most companies it is the majority. ## Don't miss the fourth guide. Sign up for free and get these practical guides delivered directly to your inbox. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## Before the next planning meeting Take one thing your team wants faster and finish this sentence about it before the meeting: > When **\[something happens\]**, we need **\[a channel or a screen\]** to reflect it within **\[a time\]**, because **\[what the customer would see\]**. If the last blank is hard to fill, you probably have your speed already. Then agree what should happen when the data arrives late or looks wrong, because at the faster speeds that stops being hypothetical. The meeting itself tends to stall in the same four places: 1. Somebody quotes streaming for a nightly problem. 2. One request really does need the top speed. 3. Nobody knows how fast the thing goes stale. 4. Somebody says the platform already does real time. Side 2 of the sheet has a sentence for each of those. One number to take into the room with you: > How often the destination system ingests. It settles more of these than any argument will, and a daily platform makes everything upstream of it daily, no matter what you paid. [Guide 2](https://www.martechtherapy.com/how-to-write-a-data-request-someone-can-act-on/) was about writing a request somebody can act on, and its third question asks when the data has to be there and why then. This is the guide that tells you what to put in that sentence. ![](https://storage.ghost.io/c/57/c5/57c5ffb5-ecd9-4bf6-b870-68986d981176/content/images/2026/10/talking-to-data-engineering-03-what-real-time-actually-costs-shot.png) Take it into the planning meeting Two sides of A4\. Five speeds, sixteen decisions placed, and four sentences for the meeting. [Download the PDF ](https://www.martechtherapy.com/content/files/2026/10/talking-to-data-engineering-03-what-real-time-actually-costs.pdf) **Next in this series:** same customer, different records. All six live on the [Helping Marketing Talk to Data Engineering](https://www.martechtherapy.com/talking-to-data-engineering/) page as they publish, and every term across the series is collected in the [glossary](https://www.martechtherapy.com/glossary/). --- ## About the series #### Series Sponsorship Disclosure Databricks came to me in the summer of 2026, after the agentic CDP series, and asked whether I would write a set of practical guides for marketers. There are six of them, and you are on the third one. Here is the arrangement in full. Databricks reviews each guide before publication and may suggest factual corrections. Anything they flag as factually wrong, I fix. Anything they would prefer I said differently, I do not. The conclusions, the structure and the tone are mine, and so is the decision about what goes in and what stays out. The guides are educational resources, not product recommendations. None of the six guides names a Databricks product, and none of them concludes that you should buy one. Would I have written something like this anyway? Probably, eventually, in pieces. Their support is why it happens now, as a series, with enough time to do it properly. Nothing here is gated. No form, no email capture, and the PDF is a direct download. If you think I have something wrong, or have overlooked an important perspective, please tell me. I would rather know. Do you have any questions after reading this article or guide? Or need support with your Martech projects? [Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)