Resources you provision
The Data Platform is a set of resources you create, not a database you administer. This page is the inventory: what you can provision, where it lives, and what every one of them carries whether you asked for it or not.
Everything here is created inside a workspace or a clean room. Nothing here is a cell-internal store. The cell's own state is architectural plumbing that the cell manages for itself, and you will never size, back up, or query it.
What a workspace gives you on day one
Provisioning a workspace is not creating an empty folder. Every entity gets one automatically, and creating it materializes a working environment:
- a workspace record with an owner membership,
- a dedicated object-storage namespace, so storage isolation is structural rather than a prefix convention,
- a messaging inbox,
- default streams, and
- an access profile (open, restricted, sensitive, or regulated) that classifies what the workspace is for.
The resource inventory
Catalog resources
The catalog addresses everything through a consistent three-level name:
catalog → schema → asset, so catalog.schema.table means the same thing to
every engine.
| Resource | What it is |
|---|---|
| Catalog and schema | The two namespace levels above an asset |
| Tables | Managed tables in open lakehouse formats, plus external tables registered from a connection |
| Views | Including materialized and streaming views with incremental refresh |
| Volumes | Governed locations for files rather than rows |
| Functions | Your own code, reachable from five different call sites (see below) |
| Connections | Registered foreign databases, object stores, catalogs, and SaaS content sources |
| Models | A model is a catalog object, created and altered like a table |
| Streams | Named, workspace-scoped real-time streams |
| Structures | Counters, sets, sorted sets, streams, sketches, and CRDTs. See Structures |
| Graphs, vector spaces, document collections | Registered into the catalog behind one shared protocol, so the catalog is complete across engines rather than SQL-only |
Storage resources
| Resource | What it is |
|---|---|
| Namespaces | A hierarchical tree with cached path resolution, per-namespace policy, and classification as a property enforced in the data path |
| Objects | Versioned on every write, with delete markers rather than destructive deletes |
| Access keys and presigned requests | For the workspace's own S3-compatible surface |
| Tiering and retention rules | Per-bucket lifecycle, bounded by a classification floor |
See Object storage.
Messaging resources
| Resource | What it is |
|---|---|
| Subjects and partitions | The addressable units of the durable bus |
| Subscriptions and consumer groups | With durable cursors and four rebalance strategies |
| Inboxes | Per-entity, including per-agent inboxes |
| Schema registry entries | Validated per subject, with strict, warn, or off enforcement |
See Messaging.
Work and product resources
| Resource | What it is |
|---|---|
| Pipelines and flows | Connector drain, transform, sink write, spread across cells |
| Notebooks | Versioned immutably on named branches, bindable as pipeline tasks, schedulable, publishable as an API endpoint |
| Data products | A dataset with typed input and output ports, a contract, certification, and a provenance envelope |
| Shares | Workspace shares, Delta Sharing recipients, and Iceberg REST grants |
| Exchange listings | A signed cross-organization offer |
One function, five call sites
Functions are worth calling out separately, because one function object is reachable from five places behind one sandbox:
- as an ETL transform step in a pipeline,
- as a column mask bound by data-security policy,
- as an AI function invoked from SQL,
- as an agent function an agent may call, and
- dispatched to a peer cell when the data lives elsewhere.
The isolation tier it runs in is computed, not chosen: it is resolved from code trust, data classification, and the cell's regime, and classification raises the tier. An author may demand more isolation than the computed tier, never less.
What every resource carries
This is the part that is easy to miss and is the whole argument of the platform. You do not opt into it, and there is no path that skips it.
| Carried | Meaning |
|---|---|
| A workspace scope | Every asset belongs to a workspace or a clean room, enforced beneath the query rather than above it |
| A classification | From the five-rung ladder, plus compartments as an orthogonal need-to-know axis |
| A lineage record | A capture guard runs before the write commits. A mutation that cannot be captured leaves a durable coverage gap by default, and can be configured to be rejected outright |
| An audit trail | Including reads. "Who looked" is a first-class question |
| A cost | Metered and attributed to an entity, into a hash-chained chain |
A message carries all five. So does an object. So does a table. That is what "one substrate" means in practice.
Agents provision these too
An agent is not a client of this inventory, it is a citizen of it. An agent holding the right grant can define a model, create a table, admit a party to a clean room, or run a query, at both workspace and clean-room scope, through the same gate a human operator crosses. The resources it creates carry the same five properties, attributed to the agent's own identity.
Related
- Workspaces and clean rooms, the boundary all of this lives inside.
- Engines and access methods, the surfaces you reach these resources through.
- Governed reads, what happens when you read one.
- Set up data-platform resources, the how-to that creates them.