Self-serve data domains.
Governed by design.
A renamed column can break a dashboard for three months before anyone notices. DataSpaceHQ gives every team the same shape — where data lands, how it's typed, who can read it, and what it promises downstream — inside rules you write once. You still write your own SQL.
It's a page in Snowsight. Not another tool.
One install wires these together.
Snowflake's own objects, created and kept in sync for you.
Core platform
- schemas
- tables
- views
- virtual warehouses
Horizon governance
- tags
- data classification
- masking policies
- tag-based masking
- access history
Apps & development
- Native App Framework
- Streamlit in Snowflake
- Container Services
- compute pools
Data engineering
- tasks
- stored procedures
Analytics
- Semantic Views
- Snowsight
Open ecosystem
- Iceberg tables
Monitoring
- ACCOUNT_USAGE metering
Every team builds it differently. The rules live in a wiki.
A wiki documents rules; it never enforces them. So the shapes drift, and a routine change nobody was watching turns into a quarter of wrong numbers.
- ✗Every new dataset, pipeline and grant waits on the same few people — or stops being asked for.
- ✗Nobody can safely navigate another team's data, so nobody notices when it breaks.
Every team picked a shape that made sense to them. Now nobody can find anything in anyone else's.
Every team gets the same shape. A change that would break it is refused before anything is built.
An agent will build against your data this year.
It follows the rules it can find.
Cortex Code, Claude Code, whatever comes next — they enforce the governance that already exists in your account. They don't add any.
Point one at a bare schema and it reads every column in the clear, writes wherever it likes, and guesses your layout from the table names. Point the same agent at a governed domain and the personal columns come back masked, the layout is the one every domain has, and there is a file telling it what not to touch.
We're not an AI product. We're the rules an AI reads first — generated from the tags actually on your tables.
Three steps. That's it.
You say what the domain should contain. DataSpaceHQ builds it and enforces your rules — no containers, tasks or grants to wire yourself.
Say what you need
Fill in the tables and columns for a new domain — or point at one you already have, even in another database. No SQL to write.
DataSpaceHQ builds it
Standing in minutes: where raw data lands, typed layers above it, and a governed way out. Your rules are checked first: if one fails, nothing is created at all.
Other teams use it
A governed HTTP endpoint, or a Snowflake view for SQL users. Callers sign in, send no SQL of their own, and see personal columns masked unless your rules say otherwise.
Your data didn't wait for a clean slate. Neither do we.
Most of what needs governing already exists — built by someone who left, named three different ways. Point at it; not a row moves.
Autonomy for your teams.
One set of rules — yours.
Write the rules once. Every domain comes out the same shape and inherits them, so any team can move without waiting on you.
Recognise any of this on your own Snowflake?
Built for teams scaling on Snowflake.
If three or more of these are true, this was built for you.
The things people ask first.
Isn't this just an API in front of Snowflake?
No. The endpoint is the easy part. DataSpaceHQ builds the whole governed domain — where raw data lands, the curated tables, who owns it, what's personal, what it costs — and enforces your rules across every one of them from one page inside Snowsight. An API is just one way to read the result.
Does my data leave Snowflake?
Never. DataSpaceHQ is a Native App that runs entirely inside your Snowflake account. Nothing is copied to us or anywhere else. You pay Snowflake for compute directly; we're a software layer on top.
Do we still have to wire up containers, tasks and roles ourselves?
No — DataSpaceHQ uses them, you don't wire them. Ingest validates each event and lands it in your raw layer; the transform layer is generated for you — typed projections from raw through to curated, running natively in Snowflake; serving runs on Snowpark Container Services; governance maps to real Snowflake tags, masking policies and roles. Standard Snowflake underneath, set up properly by default. If you already run dbt, it keeps working alongside — we're not asking you to move it.
What about data that lives in Databricks or another lakehouse?
On the roadmap: govern and serve data in an external Iceberg catalog (Databricks, Glue) through Snowflake — without moving it. If that's your setup, tell us — we're picking design partners for exactly this.
We already use dbt contracts, or looked at Gable.
dbt contracts only cover models built in dbt. Gable requires instrumenting your producer's codebase. DataSpaceHQ's contracts reach adopted tables too — including data that existed years before DataSpaceHQ did, in a database it didn't build. And it works with your dbt rather than around it: every domain can generate a dbt project — sources pinned to its raw layer, the declared casts as staging models, and the contract as tests your own CI runs. We don't execute it. Your pipeline does, in your repository, where your business logic already lives.
Can we just describe what we want in plain English?
Yes, if Cortex is enabled on your Snowflake account: describe the domain and Snowflake's own AI drafts it, inside your account, for you to check and confirm before anything is created. It's an option, not the way in — the form does the same job, and both are checked against the same rules. Nothing is ever created without you pressing the button.
What are we depending on when we install this?
Nothing of ours. DataSpaceHQ is a Native App installed in your Snowflake account — there is no hosted service of ours to lose, no licence server to phone home, and no credentials on our side. It keeps running whether or not we do. What it produces is yours and open: the data contract is ODCS, a Linux Foundation standard; the rules file is plain markdown; tagging, masking and roles are real Snowflake objects you can read and change without us; the transform is plain Snowflake SQL. One honest caveat, because it is how Native Apps work: domains this app creates live in the app's own database, so moving them out is a CREATE TABLE … AS SELECT — normal Snowflake, no export tool, no proprietary format. Tables you adopt never moved in the first place.
What does it cost?
Pricing scales with how many domains you run. We're not publishing tiers while we're still shaping the product with design partners — book a walkthrough and we'll talk through what fits your setup.
Is it production-ready today?
The core mechanics run today — install the app, provision a domain, get a governed, masked, cost-capped output port. Not a slide. It's still early: a small group of design partners, hands-on, shaping the roadmap with us. If you're scaling on Snowflake and this is already your week, now is the moment to get in.
See it on your data.
Twenty-five minutes. I build a governed domain in front of you, end to end. Nothing to install to watch it.
If it fits, we talk about a design partnership: you run it on your own Snowflake, I shape the roadmap around what you actually hit. Free while we're at this stage.
Book a walkthrough →