Exports

What exports do#

An export job reads a table or a read-only SELECT from a database connector, formats the rows as files, and writes them to a storage connector on a schedule. Use it for partner hand-offs, archival snapshots, and feeding downstream tools that want files rather than a database session.

Exports are the mirror image of file ingestions: same storage connectors, opposite direction.

Before you begin#

• Role. A viewer can read export jobs and run history. An editor is required to create or edit a job — and also to use Validate SQL and Preview, because both execute against the source database.
• A source connector: Postgres, CockroachDB, MySQL, or SingleStore.
• A destination connector: local, S3, Azure Blob, GCS, FTP, or FTPS.

Warning. MariaDB appears in the source picker but is not supported. Saving a MariaDB-sourced export always fails with source engine 'mariadb' is not a supported export source yet. Export from a supported engine, or replicate the data first.

The builder#

Four steps: Source → Format → Destination → Schedule & review.

Step 1 — Source#

For a custom query, press Validate SQL before continuing. It checks the statement against the live connector and reports the resulting columns, so you catch a typo or a missing schema qualifier before the first scheduled run.

SELECT order_id, customer_id, order_total, ordered_at
FROM sales.orders
WHERE ordered_at >= CURRENT_DATE - INTERVAL '7 days'

Step 2 — Format#

Compression rules:

• snappy is valid for Parquet only. Choosing it with any other format is rejected.
• gzip appends .gz to the filename — except on Parquet, which carries its compression codec internally and keeps the .parquet extension.

Preview runs the configured SELECT with LIMIT 50 and shows a sample. It writes nothing to the destination — it is safe to run repeatedly while you tune the query, and it requires the editor role because it queries the source.

Step 3 — Destination#

Filename template

The template accepts exactly three tokens — no others are substituted:

A typical template:

{name}_{ts}_{part}.csv

Always include {part} when Rows per file is set — without it every part overwrites the last.

Modes

An empty result still writes one header-only file, so downstream consumers see a file every cycle rather than an ambiguous silence.

Step 4 — Schedule and review#

Note. All schedule times are UTC, including the daily and weekly time pickers and any cron expression. Convert from local time before entering it.

Running an export#

Run now lives on the exports list page, not on the job's detail page.

A disabled job cannot be run:

export is disabled; enable it before running

Enable the job from the list, then run it.

Run history#

Each run records:

Open a run to see its log lines and the path of every file it wrote — the quickest way to confirm where a partner's data actually landed.

A retry does not overwrite the original run: it creates a new run row with an incremented attempt number, so the failure and the recovery both stay in the history.

Deleting an export#

Deleting is a soft delete: the job disappears from the list and stops running, and its history is retained. Ask your administrator if you need a deleted job restored — see Retention.

Field reference#

Failure modes#

Related pages#

• Data connectors
• File ingestions — files in, rather than out.
• Schedules and Executions
• Retention