Data 360
Accelerated Data Lake Objects: when zero copy is too slow to ground an agent
Zero copy federates a query out to Snowflake or BigQuery every time it runs, and your agent inherits that latency. Accelerated Data Lake Objects cache the answer inside Data 360 and refresh it on a schedule. The when-to-accelerate call, when to stay live, the incremental-refresh cost trap, and how data locality decides whether federation is fast or unusable.
A zero-copy Data Lake Object is not a copy of anything. When a retriever or an agent action reads it, Data 360 turns that read into a live query against Snowflake, BigQuery, Databricks, or Redshift, and waits for the warehouse to answer.
The demo where you point at a warehouse table and see data with no pipeline is real. What it hides is that every later read pays the round trip again, at the mercy of whatever else is running on that warehouse.
Fine for a table an analyst opens twice a day. A problem the moment an agent grounds on it, because now the round trip sits inside the reasoning loop of a live conversation. My rule: federate by default, accelerate the objects your agents and dashboards touch on every request, and physically ingest only when even a cached copy can’t hold the freshness you need.
Data 360 gives you all three modes per object. Picking the wrong one is the difference between a retriever that returns in 400 milliseconds and one that times out on a busy Tuesday.
The three federation modes, and what each one does
Zero copy in Data 360 is not one thing. It resolves into three connection methods, and you choose per data stream, not per org. If you have only read the zero-copy overview, this is the layer underneath it.
Live Query is pure federation. Nothing persists in Data 360 except the curated views you build on top, and every read pushes down to the source as a query. When the whole query pushes down, the filters, the aggregation, the joins, it moves almost no data and comes back fast. Reach for it on operational dashboards and real-time personalization, where the number has to be current to the second.
Cached Acceleration, also called an accelerated query or an Accelerated Data Lake Object, keeps a local copy inside Data 360 and refreshes it on a schedule from 15 minutes to 7 days. Reads hit the cache, not the warehouse, so they stay fast and put no load on the source. You trade freshness for latency and stability, which is the right trade when the same query runs often and slightly stale data is fine. That covers most segmentation, most BI, and most agent grounding.
File Federation points at the files in a lake, Iceberg or Delta tables in object storage, rather than issuing SQL to a compute engine. It costs the same credits as Live Query but generates no load on the external warehouse. When your lake and Data 360 sit in the same region, the cost on both sides is close to nothing, so for a large lakehouse this is often the best default of the three.
The mistake I see most is treating “zero copy” as a single decision made once. Choose per stream. The same warehouse can feed one table live and another one cached.
Why an agent makes this decision urgent
A dashboard that takes four seconds to load is annoying. An agent that takes four seconds to retrieve grounding is broken.
Point an Agentforce retriever at a live-federated DLO and the agent’s response time now includes a synchronous query to your warehouse, inside the reasoning loop, on every turn that touches that data.
If Snowflake is busy, your agent is slow. If the warehouse hits a concurrency limit, retrieval fails and the model either apologizes or answers from nothing. The latency you can’t see in a dashboard becomes latency the customer hears on the phone.
The grounding layer is where I reach for acceleration first. The data an agent reads on every request, product catalogs, entitlement tables, policy documents, account attributes, is exactly what belongs in a cache, refreshed as often as it really changes.
A product catalog that updates nightly does not need a live federated query on every customer turn. Cache it, refresh it at 3 a.m., and the retriever reads a local copy at memory speed. The move that keeps agent latency down keeps your credit bill down too, because you stopped re-running one query thousands of times a day.
Live Query is a phone call to the warehouse. Cached Acceleration is a photograph you refresh on a timer. An agent wants the photograph.
The incremental-refresh trap that inflates the bill
Cached Acceleration sounds free once the cache exists. It is not, and the reason catches teams out.
Federated reads meter per row processed. Community credit guides put the zero-copy connector rate around 70 credits per million rows processed, and an accelerated object also bills a batch data pipeline to build and refresh the cache.
Verify the current multipliers against your own rate card and Digital Wallet before modeling this, because the numbers move and differ by connector. The durable part is the shape: acceleration converts many expensive federated reads into one scheduled refresh plus cheap local reads.
Incremental refresh is where it bites. It does not mean Data 360 knows which ten rows changed. Each refresh, it processes every row in the source to work out what moved. A million-row table bills a million rows processed every time, whether ten rows changed or a hundred thousand. Set it to refresh every 15 minutes and you have signed up for 96 full-table passes a day.
The refresh interval is not a freshness knob. It is a cost knob wearing a freshness label. Match it to the decision the data feeds, not to how fresh you wish the data were. A renewal-risk score recomputed nightly does not need a 15-minute cache under it, and forcing one is how most credit overruns start: a cadence nobody set on purpose, running more often than anything reads it.
Choosing a mode, per data stream:
read pattern freshness need → mode
─────────────────────────────────────────────────────────────
ad-hoc, few times/day to-the-second → Live Query
agent/dashboard, constant minutes-to-hours OK → Cached Acceleration
large lakehouse tables matches file cadence → File Federation
sub-second + source flaky can't tolerate stale → physically ingest
Refresh interval for a cache = how often the DECISION changes,
not how fresh the data could theoretically be.Data locality decides whether Live Query is fast or unusable
Stay live and one factor dominates performance, and it is not the size of the table. It is where the data for the query lives.
If every table a query touches sits in the external system and the whole query pushes down, federation is as fast as it gets. Data 360 sends the SQL, the warehouse does the work, a small result comes back.
Trouble starts when a query straddles the boundary: a join between a federated warehouse table and a DLO that lives inside Data 360. The join can’t push down. Data 360 pulls large amounts of intermediate data across the wire to finish it locally, and that transfer is the slowest thing you can do with zero copy.
Two moves keep you out of that hole. Keep a query’s tables on the same side of the boundary so the whole thing pushes down; if an agent action joins federated data to local data on every call, that join is your latency, so accelerate or ingest the federated side and the boundary disappears.
Then sort or partition the source table on the field you filter by most. If you nearly always query the last 30 days of transactions, sorting by transaction date lets the warehouse prune the rest and scan a fraction of the table. Fewer rows scanned means faster answers and a smaller credit line.
When zero copy is the wrong tool entirely
Federation has a floor. Below it, stop federating and ingest a real copy. Four situations sit below it.
High-frequency, low-latency reads against a source you don’t control. A CRM Analytics dashboard firing ten or twelve concurrent queries can saturate the external system’s concurrency limits, and your queries queue behind everyone else’s. Cache it or ingest it.
Heavy pre-consumption transformation. If mapping the external data into the Customer 360 data model needs serious reshaping, do that work upstream in the warehouse or a real pipeline. Federation is a thin window, not a transformation engine.
Availability-dependent workloads. Live Query has no local fallback. If the warehouse is down, the data is gone until it returns, and so is any agent grounded on it. A cache at least serves its last good copy through the outage.
Trigger-dependent automation. In Live Query mode the call always originates from Salesforce reaching out, so an external change can’t reach back in to fire a Flow. If you need the warehouse to push events into Salesforce, that is a different integration pattern, not zero copy.
What I would set up
Start federated, because the cheapest data to manage is the data you never copied. Connect the source, map the streams, and leave them on Live Query while you learn the real read patterns from Digital Wallet.
Then promote to Cached Acceleration every object that an agent retriever, a segment, or a heavy dashboard reads on a repeating basis. Set each cache’s refresh interval to the slowest cadence the downstream decision tolerates, and watch the batch-pipeline line on your bill for a fortnight; a cache refreshing far more often than anyone reads it is the first thing to slow down. For a large lakehouse, prefer File Federation and keep Data 360 in the same region as the lake so the transfer cost stays near zero.
Reserve physical ingestion for the narrow band where even a cache can’t keep up: sub-second freshness against a source that can’t take the query load, or a workload that has to survive the source going dark. Everything else is a federation-versus-acceleration call, made per stream and revisited when the read pattern changes.
Get that call right and an agent grounded on warehouse data feels local. Get it wrong and the warehouse’s worst Tuesday becomes your customer’s.
Understanding the basics
What is an Accelerated Data Lake Object in Data 360?
An Accelerated Data Lake Object is a zero-copy data stream running in Cached Acceleration mode. Instead of federating every read out to the external system, Data 360 keeps a local copy and refreshes it on a schedule from 15 minutes up to 7 days. Reads then hit the cache rather than the warehouse, so they are faster, more predictable, and put no load on the source.
Does Cached Acceleration cost more credits than Live Query?
It changes the shape of the cost rather than simply adding to it. Live Query meters every federated read, so a query that runs thousands of times a day pays thousands of times, while acceleration replaces those with one scheduled refresh plus cheap local reads. The catch is that each refresh processes every row in the source, changed or not, so a cache set to refresh too often can cost more than the live queries it replaced. Verify current per-connector rates against your Digital Wallet before modeling it.
When should I physically ingest data instead of using zero copy?
When you need sub-second freshness against a source that can’t absorb the query volume, when the workload must survive the external system going offline, or when you need heavy transformation before consumption. Zero copy has no local fallback and is a thin federation window, not a transformation engine. If any of those three constraints bind, copy the data in and manage a real pipeline.
Why is my zero-copy query slow?
Almost always because the query can’t fully push down to the source. A join between a federated warehouse table and a local Data 360 object forces Data 360 to pull large intermediate results across the network and finish the work locally, which is the slowest path. Keep a query’s tables on the same side of the boundary, sort or partition the source on the field you filter by most, and accelerate the objects an agent reads on every turn.
Staring at a Data 360 bill that outran its forecast, or an agent that grounds beautifully in the demo and stalls in production? Getting the federation-versus-acceleration call right on every stream is exactly the kind of work we do. Talk to us about your data foundation.
