Multi-platform data environments are now the norm rather than the exception.
Many large enterprises have multiple data platforms such as Snowflake, Databricks, Fabric or SAP Datasphere/BDC. The longstanding problem has been that data stored natively in one platform is effectively trapped there: replication jobs, ETL pipelines, and costly egress fees are the usual workarounds.
Apache Iceberg tables change that calculus significantly and understanding where they genuinely help (and where they do not) is one of the more consequential architectural decisions data leaders are making right now.
What Snowflake and Databricks Are Both Betting On
Both Snowflake and Databricks have made substantial commitments to Apache Iceberg as an open table format sitting on cloud object storage (typically S3, ADLS, or GCS).
Rather than proprietary storage formats owned by the platform, Iceberg tables store data as Parquet files with a separate metadata layer handling schema evolution, partitioning, and versioning. Both platforms can read and write to the same underlying files, meaning a table created and maintained in Snowflake is, with the right configuration, directly queryable in Databricks, and vice versa.
Snowflake supports both managed Iceberg tables (where Snowflake owns the metadata catalogue) and external Iceberg tables (where an external catalogue such as AWS Glue or Databricks Unity Catalog holds authority).
Databricks, through Unity Catalog's native Iceberg support, offers the same flexibility from the other direction. The practical result is that cloud storage becomes the integration layer, replacing point-to-point data movement between platforms.
Where This Changes Enterprise Architecture
The interoperability story is compelling, but the more underappreciated benefit is what Iceberg does to your architecture's layer count.
A persistent challenge in mature data platforms is duplication: data lands in bronze, gets transformed and versioned in silver, and is sometimes replicated again purely to provide audit trails or rollback capability. Iceberg tables provide time travel, schema history, and snapshot isolation natively at the storage layer. For silver and intermediate layers where these capabilities were previously handled by platform-native constructs or bespoke engineering, Iceberg removes the need to build and maintain that logic twice.
Fewer layers means less storage cost, less pipeline complexity, and fewer failure points to manage.
There is a performance trade-off to name directly. Iceberg tables carry a modest overhead compared to fully native formats (Snowflake's native tables or Databricks Delta native storage) because the query engine traverses the external metadata layer rather than relying on platform-optimised internal structures. For most transformation and exploration workloads this is imperceptible. For gold-layer tables powering front-end dashboards and executive reporting, where sub-second query response is a user experience expectation rather than a nice-to-have, the recommendation is straightforward: use native objects. Iceberg belongs in your interoperability and intermediate layers, not in your BI-facing serving layer where latency directly affects adoption.
SAP BDC: Iceberg Is Key
The SAP dimension deserves particular attention for organisations running hybrid architectures. Iceberg tables are the key mechanism enabling data sharing between Snowflake and SAP Business Data Cloud (BDC).
A pattern we see regularly involves non-SAP source data (third-party commercial data, CRM systems, operational platforms outside the SAP estate) being combined with SAP transactional data in Snowflake to produce enriched datasets. When those enriched datasets then need to flow back into SAP Analytics Cloud for integrated planning, covering financial forecasting, demand planning, or workforce planning, Iceberg tables provide the bridge.
Without this, you are back to file exports, custom connectors, or replication pipelines that introduce latency and version drift.
With Iceberg as the shared layer, BDC can consume Snowflake-maintained data without requiring that data to move or be reformatted. For organisations where SAP Analytics Cloud is the planning tool of record and Snowflake holds critical non-SAP data then Iceberg is required to enable this architecture to function.
Key Takeaways
- Layer appropriately: Use Iceberg for bronze and silver layers where interoperability, time travel, and schema evolution take priority. Reserve native platform formats for gold-layer objects where query performance is non-negotiable.
- Reduce replication: In multi-platform environments running Snowflake alongside Databricks, Iceberg on shared cloud storage reduces the need for pipeline-based data movement between platforms.
- SAP BDC integration: For enriched datasets that originate outside the SAP estate but need to feed SAP Analytics Cloud planning workloads, Iceberg tables in Snowflake are the practical enabling architecture.
- Functionality equivalence: Time travel, schema evolution, and partitioning are all supported natively in Iceberg, so the functional gap versus platform-native tables is smaller than most teams expect.
- Vendor flexibility: Standardising on Iceberg for shared data assets gives your organisation meaningful architectural flexibility as the platform landscape continues to evolve.
Snap Analytics works with enterprise data teams navigating complex, multi-platform environments. If you are evaluating where Iceberg fits in your architecture, or working through the Snowflake and SAP BDC integration, we would be glad to share what we are seeing in practice.