Limits#
Everything here is a real number from the running system, and each one names its
consequence. If behavior ever disagrees with this page, that's a bug in one of
them — tell us.
| What | Limit | When you hit it |
|---|---|---|
| Source sync cadence | Every 4 hours per source | Not a limit you hit — syncs are spread within the window so sources don't all fire at once |
| Interactive query | 10 minutes | The query stops and the Queries page shows the timeout; move long work into a model |
| Model refresh, per model | 4 hours | The run marks the model failed and continues with models that don't depend on it |
| Models refreshing at once | 4 per organization run | Others wait inside the same run — dependency order is never violated to go faster |
| Model runs | 1 at a time per organization | A Run now during a run is queued, not lost |
| Any single statement | 12 hours | The hard ceiling for everything, models included; the statement is refused further work |
| Send without confirmation | 500 changed rows | The run pauses and asks you to confirm — and any run that would create records always asks, regardless of count |
| Agent (MCP) query results | 500 rows / 100 KB / 5 minutes | Results truncate with a marker; narrow with where and limit |
Queries and memory#
You don't size machines. If a query runs out of memory, Supernova retries it
automatically on a larger one; you see one slower query, not a failure. The 10
minute interactive ceiling spans those retries — it's a promise about your time,
not per-attempt bookkeeping.
Long work belongs in models#
The interactive ceiling exists because a query you're waiting on and a query
that runs on a schedule deserve different budgets. A model gets 4 hours per
refresh and doesn't hold your attention hostage while it works. If a query
keeps brushing the interactive limit, make it a model —
writing models takes about a minute.
Consistency, not speed, is the guarantee under load#
However long a query runs, it reads one consistent snapshot of every table —
a sync committing mid-query changes nothing about that query's view.
Snapshots and the rules of the lake: your lake.
Sends are deliberately careful#
Send runs write to systems your team lives in, so the ceilings are conservative
by design: a diff against the last run keeps re-sends from happening at all, dry
runs preview without writing, and the 500-row confirmation gate means no model
bug can silently rewrite your CRM. Details on the send pages.