--- title: "Warehouse export" slug: admin/warehouse url: https://projectri.com/docs/admin/warehouse section: admin audience: admin app_route: "/[slug]/admin/warehouse" permissions: [warehouse.view, warehouse.manage] plan: reporting.warehouse mobile: "/admin/warehouse" updated: 2026-09-08 source: Projectri documentation --- # Warehouse export A scheduled copy of this workspace into your own object storage, in a published and versioned schema, with run history, watermarks and a dry run. ![Warehouse export](https://projectri.com/docs-shots/admin-warehouse.png) ## 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 > [!WARNING] > A warehouse export is permission-blind. Everything in the selected tables > leaves the workspace, cost and margin included, regardless of who can see what > inside Projectri. - **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](/docs/admin/reports) — reporting inside Projectri rather than outside it. - [Exports](/docs/features/exports) — the other ways data leaves. - [Privacy](/docs/admin/privacy) — retention and residency, which this export sits alongside. - [Security](/docs/admin/security) — the console section this page belongs to, and why. ## Related - [Reports](https://projectri.com/docs/admin/reports.md): Workspace-wide reporting over a rolling window — budget against spend, effort against capacity, and portfolio health worst first, each exportable as CSV. - [Security](https://projectri.com/docs/admin/security.md): The sign-in rules this workspace enforces, who is signed in, what machine credentials and outside applications can reach it, and the sign-in history. - [Privacy](https://projectri.com/docs/admin/privacy.md): The data-subject request queue with its statutory clock, how long each category of data is kept, legal holds that suspend deletion, and where this workspace's data lives. - [Reports](https://projectri.com/docs/workspace/reports.md): The fixed report page — completion, throughput, burndown, team performance and the effort figures, for this week, this sprint, this month or all time. - [Exports and downloads](https://projectri.com/docs/features/exports.md): What you can take out of Projectri, in which formats, who is allowed to, and what a download deliberately leaves behind.