Apache Iceberg in Data 360: file federation, the REST catalog, and the open-table bridge zero copy was missing

Every zero-copy story starts the same way: someone in the room says “we already have all this in the lake, we don’t want to copy it into Salesforce,” and someone else nods and clicks Snowflake connector. That’s fine right up until the data you actually need isn’t in Snowflake. It’s an Iceberg table another team curated in S3, governed by Lake Formation, and there is no per-vendor connector for “our data lake.” This is exactly the gap file federation fills — and the reason it exists is that Data 360’s own storage is Apache Iceberg underneath, so an open-table bridge was always the more honest architecture than a connector per warehouse.

We’ve written about what zero copy actually moves and what it costs, and about the platform-versus-platform framing that procurement keeps reaching for. This post is the layer beneath both: the open table format itself. What an Apache Iceberg File Federation connection is, how the REST catalog and AWS Lake Formation actually govern access, how it differs from the native connectors, and the three places where “query in place” quietly becomes “materialize a copy.”

Iceberg is the substrate, not a new feature

Start with the fact almost nobody selling you a connector mentions: Data 360’s lakehouse is built on Apache Iceberg. Salesforce’s own engineering team has described running the Data Cloud lakehouse on Iceberg at a scale of millions of tables and tens of petabytes. That matters because it changes what “zero copy” can mean. When both your lake and Data 360 speak the same open table format, the integration doesn’t have to be a bespoke connector that translates one vendor’s dialect into another’s — it can be a shared catalog pointing at shared Parquet files, read by whichever engine needs them.

Apache Iceberg is a table format, not a storage engine. It sits on top of ordinary Parquet files in object storage and adds the metadata layer a warehouse gives you for free: schema, partitioning, snapshots, and — crucially — a catalog that tells any engine which files make up the current version of a table. Give Data 360 credentials to that catalog and it can read the table directly from S3 with its own compute. No Snowflake warehouse spun up, no Databricks cluster, no second copy. That’s the whole idea, and it’s a genuinely different mechanism from the connector-based zero copy most teams have used so far.

Two directions, and people conflate them constantly

“Zero copy” is used for two opposite data flows, and mixing them up is the fastest way to design the wrong thing.

• File federation (inbound). External Iceberg tables become queryable inside Data 360. The data stays in your S3 bucket; Data 360 reads it in place. This is what you set up when the lake is the source of truth and you want Data 360 to unify, segment, or ground an agent on it.
• Data sharing (outbound). Data 360 objects are exposed as live views inside an external warehouse. In Snowflake the share shows up under Private Sharing and you query it like a native database; equivalent targets exist for BigQuery, Redshift, and Databricks. This is what you set up when Data 360’s unified profile is the source of truth and the warehouse team wants it without an ETL job.

File federation is the direction this post is about, because it’s the one the native connectors leave a hole in. And within federation, the important split is connector federation versus file federation. Connector federation (Snowflake, BigQuery, Redshift, Databricks) reaches into a warehouse’s own query engine over a live connection. File federation skips the warehouse engine entirely and reads the Iceberg files at the storage layer. If your data lives in a warehouse, use the connector. If it lives in a lake — or in a catalog you want to keep vendor-neutral — file federation is the door.

What an Iceberg File Federation connection actually needs

The connection has three moving parts, and getting each one wrong produces a different, unhelpful error.

1. A catalog endpoint. Data 360 talks to an Iceberg REST catalog — the standard API that returns table metadata and file locations. Salesforce launched file federation in beta in June 2025 for AWS Lake Formation, Databricks, Snowflake, and any lake exposing an Iceberg REST catalog. That last clause is the point: it’s not a fixed list of blessed vendors, it’s a protocol. If your catalog speaks Iceberg REST, Data 360 can read it. On AWS specifically, the catalog is the AWS Glue Data Catalog’s Iceberg REST endpoint, and Data 360 collaborated with AWS so that this path is a documented, supported configuration rather than a hack.

2. Storage access. The catalog tells Data 360 where the files are; something still has to authorize reading them. On AWS, that governance runs through AWS Lake Formation — you grant the federated Salesforce principal permissions on the databases and tables you want exposed, and Lake Formation enforces them at read time. This is the part teams underestimate: the catalog connection can succeed while every query returns nothing because Lake Formation was never granted table permissions. Governance is a separate, deliberate step, not an implication of the connection.

3. Object storage in the open format. The tables have to actually be Iceberg. If you’re on Databricks and your tables are Delta, they federate via UniForm, which exposes Delta tables through Iceberg metadata without a physical conversion — so you don’t rewrite the lake to participate. But a pile of raw Parquet with no Iceberg metadata layer is not a federatable table; it needs a catalog entry first.

Once those three line up, the federated table lands in Data 360 as an external Data Lake Object. And that’s where the real work starts — because a DLO is inert until you map it.

The mapping step still decides everything

Federating a table gets you a Data Lake Object, not a usable profile. Nothing downstream — unification, segmentation, agent grounding — touches a DLO directly. You have to map it into a Data Model Object, and that mapping is exactly the step we’ve argued decides everything downstream: which field is the primary key, how it types, and how it joins to the rest of your model. File federation changes where the bytes live; it changes nothing about the modeling discipline. A federated orders table with a sloppy key mapping over-merges customers just as thoroughly as an ingested one.

A minimal mental model of the flow, end to end:

Iceberg table in S3  (Parquet + Iceberg metadata)
        │
        ▼
AWS Glue Data Catalog  →  Iceberg REST endpoint      ← Data 360 connects here
        │                                              (Lake Formation grants access)
        ▼
External Data Lake Object (DLO)  ← queried in place, no copy
        │   map fields, set primary key
        ▼
Data Model Object (DMO)  →  identity resolution · segments · agent grounding

Read that diagram and the value proposition is obvious: the storage stays put, and the modeling layer you already know sits on top unchanged. Read it a second time and you’ll spot where the promise gets tested — everything from the DMO down assumes it can behave as if the data were local.

Where “query in place” quietly materializes

Zero copy is a real mechanism, but it is not a universal one, and the honest version of this post is the caveats. Three of them bite in practice.

Identity resolution and heavy transforms. Unification isn’t a read — it’s a compute job that shuffles and rewrites records to build unified profiles. Running match-and-reconcile logic over federated data means Data 360 has to pull those rows across the boundary to process them. The unified profile it produces is materialized in Data 360’s own storage. So the moment you unify federated data, part of it is no longer purely “in place.” That’s not a bug; it’s physics. But it means the “we never copy anything” pitch is only true up to the point you start doing the thing you probably federated the data to do. We laid out the same trade-off in the zero-copy explainer, and it applies with full force here.

Query cost scales with what you read, every time. A federated query has no local cache of the whole table — it reads from S3 on each run. That’s cheaper than maintaining a copy when access is occasional and the table is large; it’s more expensive when a segment or an agent hammers the same slice hundreds of times a day. Data 360 bills its own processing on those reads, and the credit math doesn’t forgive a chatty federated retrieval any more than it forgives an over-eager streaming insight. Federate the cold, wide tables; think twice before federating the hot, narrow one an agent grounds on every conversation.

Not every downstream feature accepts federated input. Segmentation, activation targets, and some transform operations have historically had constraints on federated versus materialized data, and those constraints have moved release to release. The pattern to internalize: federation lands the data, but the feature you point at it may still require an acceleration step or a materialized copy to work. Before you architect a segment or an activation on top of a federated Iceberg table, confirm against current release notes that the specific downstream operation supports it — this surface has been changing quickly, and file federation itself is recent enough that GA scope is worth verifying rather than assuming.

When to reach for file federation over a connector

Three questions settle it for a given source.

1. Does the data live in a warehouse with a native connector? If it’s Snowflake or BigQuery and you want the warehouse’s own engine to serve it, use the connector — you get the warehouse’s compute and optimizer. File federation is for lakes and for catalog-first architectures.
2. Do you want to stay vendor-neutral at the catalog? If part of your bet is not being locked to one warehouse’s sharing protocol, the Iceberg REST catalog is the neutral option by design. Any engine that speaks Iceberg — Data 360, Snowflake, Databricks, Spark, DuckDB — reads the same tables. That’s a strategic reason to prefer file federation even when a connector exists.
3. Is the governance already in Lake Formation (or an equivalent catalog)? If your access policies live in Lake Formation, federating through it means you don’t re-implement grants inside Salesforce — you extend the ones you already enforce. That’s a real operational win, and it’s the opposite of the “export a CSV and lose the policy” pattern federation exists to kill.

If you’re weighing this against standing up a warehouse-to-warehouse comparison, the honest framing in Data 360 vs. Snowflake and vs. Databricks still holds: these platforms are complements joined by an open format far more often than they’re rivals, and Iceberg is increasingly the join.

The takeaway

File federation is the piece that makes zero copy a general capability instead of a per-vendor courtesy. Because Data 360 and a growing share of the data ecosystem all speak Apache Iceberg, an external table in S3 can become a queryable Data Lake Object without a connector, a copy, or a warehouse cluster — governed by the Lake Formation grants you already maintain, reached through a standard Iceberg REST catalog. Map it to a DMO with the same discipline you’d use for ingested data, federate the cold wide tables rather than the hot narrow one, and verify which downstream features accept federated input before you build on them. Do that and you get the thing the connectors couldn’t give you: your whole lake, in place, on an open format nobody owns.

Understanding the basics

What is Apache Iceberg File Federation in Data 360?

It’s a zero-copy connection that lets Data 360 query Apache Iceberg tables stored in an external object store — such as Amazon S3 — without copying them in. Data 360 connects to the lake’s Iceberg REST catalog (on AWS, the AWS Glue Data Catalog’s Iceberg REST endpoint), reads the underlying Parquet files with its own compute, and surfaces the table as an external Data Lake Object. Access is governed by the lake’s own layer — AWS Lake Formation on AWS — so you extend existing grants instead of re-implementing them. It differs from the native Snowflake and BigQuery connectors by working at the open-table-format and catalog layer, which means any lake exposing an Iceberg REST catalog can participate.

How is file federation different from the Snowflake or BigQuery zero-copy connectors?

The native connectors federate a specific warehouse by reaching into that warehouse’s own query engine over a live connection. File federation skips the warehouse engine entirely and reads Iceberg files directly at the storage layer, using a standard REST catalog rather than a vendor-specific protocol. Use a connector when the data lives in a warehouse and you want that warehouse’s compute to serve it; use file federation when the data lives in a lake, when you want to stay vendor-neutral at the catalog, or when governance already runs through something like Lake Formation.

Does zero-copy file federation ever actually copy data?

Yes, in specific cases. Reading and querying a federated Iceberg table happens in place. But identity resolution and heavy transforms have to pull rows across the boundary to compute, and the unified profiles they produce are materialized in Data 360’s own storage — so the moment you unify federated data, part of it is copied by necessity. Some segmentation, activation, and transform operations have also required an acceleration or materialization step depending on the release. Federation removes the bulk ETL copy; it doesn’t make every downstream operation copy-free.

---

Trying to decide whether a source belongs behind a connector, a file-federation catalog, or a real pipeline — and how the credit math lands either way? Talk to us. Getting the data foundation right before it grounds an agent is exactly the work we do.