Today, I'm excited to announce Open Catalog Access — a new CDP capability that publishes your CDP data as Apache Iceberg tables, queryable directly from Snowflake, Databricks, and BigQuery without copying it into a separate warehouse.
This is a significant architectural milestone for us. Here's why.
Centralization Is the Goal. Enterprise Reality Is Fragmentation.
For years, the conventional wisdom has been "centralize everything into one place." Snowflake, Databricks, BigQuery — the data warehouse became the system of record, and for good reason: centralizing data enables governance, reduces fragmentation, and powers analytics at scale.
Some organizations pull this off. But for most large enterprises, that ideal stays out of reach — not because the technology is lacking, but because enterprise data is inherently fragmented. Different teams build different systems for different purposes. Marketing's "customer" is not finance's "customer." Each system is correct within its own boundaries — yet none provides a complete picture on its own. For these organizations, the realistic path isn't forcing everything into one warehouse; it's accepting that fragmentation as a given and building interoperability on top of it.
CDPs are a clear example. They exist to unify customer identities, build audiences, and power engagement. The friction shows up the moment someone outside the CDP team wants to use that data, particularly someone from another business division who has no way to discover what customer tables exist or get access to them without going through the CDP team as a gatekeeper. So every team ended up writing its own export, one integration at a time, instead of reading from a single governed catalog.
If you can move all of your customer data into one warehouse, you should — that's exactly what Composable CDP is for. But when you can't, or don't want to operate that infrastructure yourself, the fix isn't forcing it anyway. It's putting a catalog and a permissions layer on top of where the data already lives, so every AI agent, analytics pipeline, and data science team can discover and access the customer intelligence they're authorized to see, wherever they naturally work.
What We Built
Open Catalog Access exposes your Treasure Data CDP data as Apache Iceberg tables through a managed Iceberg REST catalog. Behind the scenes, we provision:
- An S3 bucket for Iceberg table data, provisioned and managed by Treasure AI in an AWS environment isolated per customer
- An AWS Glue HMS catalog as the Iceberg metastore
- An IAM reader role with scoped, read-only access for external query engines
This is not a nightly CSV dump. This is live Iceberg table access through an open protocol, secured by AWS IAM trust policies you configure and approve on your side of each integration.
Open Catalog Access architecture: the CDP publishes Iceberg tables into a managed catalog inside Treasure AI's own AWS environment; Snowflake, Databricks, and BigQuery read from it directly, read-only.
Supported Integrations
| Data Engine | Integration Method | Status |
|---|---|---|
| Databricks | Unity Catalog federation via Glue HMS foreign catalog | GA |
| Snowflake | Catalog-linked database via Glue Iceberg REST endpoint | GA |
| BigQuery | Federated dataset via BigQuery Omni (AWS Glue) | Experimental |
| Other Iceberg-compatible engines | Direct Iceberg REST catalog API | GA |
Each integration is read-only by design. The Iceberg REST API and catalog-vended credentials (Snowflake) or scoped AWS IAM roles (Databricks, BigQuery) ensure that external engines can read what they need without modifying the source of truth.
Why Apache Iceberg
We chose Apache Iceberg because it has become the de facto standard open table format for lakehouse architectures. Not a proprietary format. Not a one-off connector. An open specification supported natively by every major data and AI platform. This means:
- Portable, not proprietary. The tables are stored in Apache Iceberg — an open, widely supported format. If you ever move off Treasure AI, your data isn't locked behind a proprietary engine or file format.
- No ETL for you to build. No reverse ETL tools, no pipeline engineering on your end. Publishing a table is a single SQL job — an INSERT INTO or CREATE TABLE AS SELECT statement, typically one operator in your existing Treasure Workflow — and Treasure AI operates the publishing infrastructure behind it.
- As current as your CDP. Tables refresh each time your workflow publishes — the catalog always reflects the latest state your CDP has published, with no separate pipeline to maintain.
Use Cases
Cross-Engine Analytics
Your data science team uses Databricks for ML pipelines. Your marketing team builds audiences in Treasure AI. Your BI team runs Snowflake for reporting. With Open Catalog Access, all three can work against the same underlying CDP data — the marketing team activates through the CDP, the data scientists train models on Iceberg snapshots, and the BI team builds executive dashboards — all without data movement.
AI Model Training
Customer data is the highest-signal training data for personalization models, churn predictors, and propensity engines. By exposing CDP data through Iceberg, your ML pipelines can read directly from the catalog without a separate data export step. The data is already unified, cleaned, and identity-resolved — the hardest part of ML pipeline engineering is done for you.
Customer 360 for External Systems
If your organization has invested in a data mesh or data product architecture, CDP data is one of the highest-value data products you can publish. Open Catalog Access lets the CDP publish data the way any other data product does — as governed tables with database- and table-level read permissions, discoverable by the engines your teams already use.
The Security Model
Data access is governed by three layers:
- AWS IAM trust policies — Each integration (Snowflake, Databricks, BigQuery) is scoped to a specific external identity. Snowflake uses catalog-vended credentials with scoped, short-lived tokens. Databricks uses IAM role federation with an external ID. BigQuery uses web identity federation.
- Database-level access control — Permissions on the Iceberg catalog control which databases each connected integration can see. From there, your own platform's access controls — Unity Catalog grants in Databricks, roles in Snowflake — govern which of your users can query those tables. Open Catalog Access controls what's exposed to the integration; your platform controls who on your side gets to use it.
- Read-only by design — The reader IAM role is read-only. External engines query; the CDP remains the system of record for writes.
This is governed through our Iceberg Catalog Management API, which also supports trust policy management, database management, and permission management — all via REST.
Why Open Standards, Not Just Open Data
The industry's response to enterprise data fragmentation has not been to abandon the goal of centralization. It has been to recognize that centralizing alone is not enough — you also need interoperability for the data that cannot be moved.
Apache Iceberg was created at Netflix not as a migration tool, but as a shared table layer that allows multiple engines to safely access the same data without tight coupling. Data mesh architectures acknowledge that central data teams become bottlenecks at scale, and propose domain-oriented decentralization as a pragmatic response — not because centralization is wrong, but because it doesn't scale operationally.
Governance is splitting the same way. Some vendors keep access control entirely inside their own engine — a closed system where a permission only means something as long as you're querying through that one engine. Others are pushing governance down into the catalog layer itself: Apache Polaris (Snowflake's open-sourced Iceberg REST catalog), Databricks' Unity Catalog, AWS Lake Formation, and open projects like Apache Gravitino and Lakekeeper are all building toward attaching permissions to the open catalog rather than to a single proprietary engine, each with its own depth of policy, masking, and audit capability. Open Catalog Access follows that same direction — permissions attached to the catalog, not locked inside one engine — starting today with database-level access. The common thread: centralize what you can, interoperate where you must.
The CDP industry is part of this same shift. CDP data, like every other category of enterprise data, should be accessible through open standards — not because CDPs are uniquely bad, but because no system should be an island in a modern data ecosystem.
But there is an important distinction in how we're approaching this at Treasure AI.
Open Catalog Access is not an alternative to Complete CDP. It is an extension of it.
Complete CDP gives you zero-ops, predictable pricing, and same-day activation — without managing infrastructure. Open Catalog Access layers open Iceberg access on top of that, so you never have to choose between operational simplicity and data freedom. If you already run Composable CDP against your own warehouse, you already have this kind of native access — Open Catalog Access exists for Complete CDP customers who want that same openness without giving up a managed, zero-ops deployment. The CDP remains the system of record. External engines are readers, not writers.
| Approach | Data location | External engine access |
|---|---|---|
| Complete CDP | Treasure AI | Via Treasure AI's REST API only |
| Complete CDP + Open Catalog Access | Treasure AI | Treasure AI REST API + Iceberg Catalog |
| Composable CDP | Your warehouse | Warehouse-native access |
This is what a managed CDP looks like when it embraces open standards. You keep the operational simplicity of a managed platform. Your data stays where it belongs. And every authorized engine, agent, and analyst in your organization can access the customer intelligence they need — without you running additional infrastructure.
Getting Started
Open Catalog Access is available today for all Treasure AI accounts running Complete CDP. Contact your Customer Success representative or support to enable it.
Once enabled, you can:
- Provision resources via our API — a one-time operation that creates the S3 bucket, Glue catalog, and IAM role
- Configure integrations — follow the setup guides for Databricks, Snowflake, or BigQuery
- Manage access — use the Permission Management API to control which databases each user can see
- Publish and Query — add a single API call to your Treasure Workflow to publish tables to the catalog; they appear in your target engine automatically
The full API reference and setup guides are available in our documentation:
What This Means
The modern data stack is not a monolith — it's an ecosystem. The companies that win will be those that can move customer intelligence to where it's needed most, at the speed their business demands, without being locked in by the system that created that intelligence.
Open Catalog Access is not just about making CDP data accessible. It's about treating customer data as what it always should have been: a first-class citizen in your data ecosystem, accessible through open standards, secured by modern governance, and available to every authorized engine, agent, and analyst in your organization.
We're excited to see what you build with it.
Open Catalog Access is available now. Visit our documentation to get started, or contact your Customer Success representative.
Frequently Asked Questions
Does Open Catalog Access work with Composable CDP?
Open Catalog Access is a Complete CDP capability — it opens read access to the managed storage that Complete CDP already operates on your behalf. If you run Composable CDP, your data already lives in your own warehouse, so external engines already have native access without needing Open Catalog Access.
Is the data read-only from external engines?
Yes. The read-only IAM role ensures that external engines (Snowflake, Databricks, BigQuery) can query tables but cannot modify data. The CDP remains the system of record for writes.
Does this increase my AWS costs?
The Iceberg S3 bucket and Glue catalog are provisioned in Treasure AI's AWS account. Storage costs for table data are included in your Treasure AI agreement. You pay for the compute consumed when querying from external engines, and depending on your query engine and region, cross-account data transfer (S3 egress) may also apply — your Customer Success representative can walk through the cost model for your setup.
How often is the Iceberg data refreshed?
Data freshness depends on your CDP pipeline schedule. Tables reflect the latest published state of your CDP data at the time of each query. We are working toward continuous incremental publication in a future release.
What about data governance and PII?
Open Catalog Access exposes only the databases your permissions allow — access control is at the database level, not row or column level. Because external engines read this data directly, standard data-handling practices in those engines — query caching, materialized views, any table you build from the result — apply just as they would for any other data source you connect. Make sure downstream usage in Snowflake, Databricks, or BigQuery follows your organization's data-handling policies.
Does this integrate with my existing enterprise data catalog?
Open Catalog Access is an access layer for CDP data, not a metadata or governance catalog — it doesn't currently register lineage, ownership, or business glossary terms into third-party catalogs like Atlan or Collibra. Registering these tables in your enterprise catalog today means treating them like any other cross-account Iceberg source: your catalog needs its own path to the Iceberg REST endpoint and the right AWS permissions, which isn't yet a packaged integration. Talk to your Customer Success representative if you want help setting that up. Deeper, native catalog integration is on our roadmap.
What happens to my data if I leave Treasure AI?
Your Iceberg table access is tied to your active Treasure AI agreement. Data export and handover terms at contract end are part of your commercial agreement, not a technical default — talk to your account team about the specifics for your contract.
Which regions are supported?
Open Catalog Access is available in all Treasure AI site regions: US (us01), Europe (eu01), Japan (ap01), and Korea (ap02). Each region has its own Iceberg Management API endpoint.
