---
title: Limits
description: Every ceiling in one place — what it is, why it's there, and what happens when you hit it.
species: reference
---

# 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](/v2/docs/models/authoring) 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](/v2/docs/concepts/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.