Warehouse export

What it is#

Warehouse export writes a copy of this workspace's data to a bucket you own, on a schedule, in a schema Projectri publishes and versions. Two tabs, in the order the conversation actually happens: Published schema, which a data team reads before agreeing to anything, and Connections, where somebody who has already decided sets one up.

How to get there#

Security → Warehouse export in the admin console. It sits under Security rather than beside Integrations for one reason: a warehouse export is permission-blind bulk egress of everything for the tenant, cost included. That is a decision a security team makes.

• Seeing connections and their run history needs warehouse.view.
• Creating, configuring and running an export needs warehouse.manage, and the reporting.warehouse entitlement (ENTERPRISE).
• Both keys are withheld from the blanket viewer grant.

Without the entitlement the connections tab still works and the schema catalogue is empty, with a line saying the columns are documented and stable and we will send them.

How to use it#

Read the schema before you connect#

1. Open Published schema. It is a contract, not a dump of our tables: hand-written, versioned, and it does not follow an internal rename — which is what stops a column disappearing from your dashboard because somebody tidied a model.
2. Ten tables: four facts (fact_time_daily, fact_expenses, fact_invoice_lines, fact_bookings) and six dimensions (dim_user, dim_project, dim_client, dim_job_role, dim_task, dim_team).
3. Each table says whether it is Incremental — only rows changed since its watermark — or Full refresh, and carries a Money mark when it holds currency.
4. Tables you will look for and not find names the deliberate absences with the reason and the workaround, so the difference between a decision and an oversight is visible.

Connect a bucket#

1. Connect.
2. Name the connection, then choose the destination. **S3-compatible object storage** is the one that works: AWS S3, Cloudflare R2, MinIO, Backblaze B2, DigitalOcean Spaces, or Google Cloud Storage through its interoperability endpoint. Snowflake, BigQuery and native GCS are listed as Not built with the workaround — point an external stage or external table at the S3 drop, because the partition layout is Hive-standard.
3. Give the bucket, region, optional endpoint and prefix, and the credential handle. Nothing in the saved configuration is a credential, and a config that looks like one is refused.
4. Choose a format — NDJSON or CSV — and a cadence: Daily, Hourly or Manual.
5. Optionally narrow the tables. Leaving the picker empty means all ten.
6. A new connection stays pending until it writes something.

Try it without writing anything#

Dry run puts the whole pipeline into memory: the same extraction, the same formatting, the same object keys. Nothing reaches the bucket and no watermark moves, so a real run afterwards still exports the same rows. It reports what it would have written, the size and how long it took.

Run it now#

Run performs a real export. The result says whether it finished cleanly or with failures, and the run history says which tables.

Diagnose a stalled export#

1. Run history lists every run with its trigger and per-table row and byte counts.
2. A table that hit the per-run row cap is named — its watermark stayed where the rows ran out, so the next run continues from there.
3. A table that did not land is named too, and its watermark did not advance, so those rows are still owed.
4. Watermarks shows where each table's incremental read resumes from. That is almost always the answer to "why is this table not updating".

Disconnect#

Disconnect asks you to type the connection's name. The connection, its run history and its watermarks are deleted outright — nothing is soft-deleted, because a customer disconnecting a warehouse is usually doing it because their security team asked. Files already in your bucket stay where they are; this only stops us writing more.

What it affects#

• Your bucket, and the bill for it. A daily connection writes every night whether or not anybody reads it.
• Nothing inside Projectri. The export reads; it never writes back.
• Your data governance. The export ignores permissions entirely: it contains everything for the tenant, including cost. The setup screen names the money tables rather than implying it, because knowing which tables carry money is what makes the decision informed.
• Watermarks and backfills. A watermark that advanced past a backfill is why historic rows never appear. Deleting the connection resets them, and so does nothing else on this screen.

On mobile#

/admin/warehouse in the Expo app answers the one question that happens away from a laptop: did last night's copy land? It reads the health of each connection as a sentence — no credential, a failing run, an overdue run, or a table that did not land — and opens a connection for its run history. Composing a connection and reading the schema catalogue stay on the web.

Limits and gotchas#

• A connection's status is not its health. It goes ACTIVE the first time it writes anything and stays there, so a bucket policy that changed on Tuesday leaves an ACTIVE connection whose last success is six days old. Read the health line and the last run, not the status word.
• Each table has a per-run row cap. A table that hits it is reported rather than silently truncated, and the next run resumes from the same watermark.
• A dry run cannot fail the way a real run does, because it never touches the destination. It proves extraction and formatting, not your bucket policy.
• Only S3-compatible destinations are built. The other three are listed so the gap is stated, not so they can be chosen.
• Disconnecting deletes the run history. If you need it for an audit, take it before you disconnect.

Related#

• Reports — reporting inside Projectri rather than outside it.
• Exports — the other ways data leaves.
• Privacy — retention and residency, which this export sits alongside.
• Security — the console section this page belongs to, and why.