---
title: Limits
description: Every Dashies size ceiling by constant name, plus the per-engine row and byte caps a cube result is measured against.
updated: 2026-08-05
---

Every ceiling on this page is read out of the server's own exported constants by
a build guard, so a raise in the code turns into a wrong number here rather than
a silently stale one. The guard reads the two tables below and nothing else, so
a figure quoted in prose anywhere on this site is unchecked.

## Per-engine cube caps

A dataset's SQL runs once per publish and once per refresh. Its result is
measured on two axes, and the ceilings differ by engine.

| Engine | Rows per result | Bytes per result | Island ceiling | Refused by | Over the island ceiling |
|---|---|---|---|---|---|
| `self` | 100,000 | 8,000,000 | 8,388,608 | executor | refused |
| `postgres` | 100,000 | 8,000,000 | 8,388,608 | executor | Parquet |
| `bigquery` | 100,000 | none | 8,388,608 | adapter | Parquet |
| `snowflake` | 100,000 | none | 8,388,608 | adapter | Parquet |
| `redshift` | 100,000 | none | 8,388,608 | adapter | Parquet |
| `databricks` | 100,000 | none | 8,388,608 | adapter | Parquet |
| `mssql` | 5,000 | 2,000,000 | 2,097,152 | executor | refused |

**Rows per result** is a hard refusal on every engine in the table. Past it the
run fails; it never returns a truncated result.

**Bytes per result** is the serialized size at which the read-only executor
raises. `none` in that column means literally that: BigQuery, Snowflake, Redshift
and Databricks are reached through a REST adapter with no database executor in
the path, and nothing on that path measures serialized size. Those four are
bounded on the byte axis only by the island ceiling and by
[`MAX_PUBLISH_BYTES`](#size-constants) at publish time.

**Refused by** names the layer that produces the refusal, because the two behave
differently. An `executor` engine measures the assembled result and raises on
overflow. An `adapter` engine reads the warehouse's own reported row total before
fetching anything and refuses up front, so an over-cap cube costs you almost no
warehouse time.

**Island ceiling** is a Worker-side backstop on the whole serialized data island,
set to the next whole binary MiB above the executor's decimal cap so a result the
database accepted is never re-refused for serializing a few bytes wider here.
It is also the threshold the authoring size recommender bands against.

:::warning{title="SQL Server is the outlier on both axes"}
`mssql` allows 5,000 rows and 2,000,000 bytes per result. That is twenty times
fewer rows than the ceiling every other engine in the table carries, and it has
no Parquet offload to fall back on, so an over-ceiling cube there is terminal:
coarsen the grain, narrow the window, or fold small dimension members into an
`Other` bucket.
:::

## What each ceiling measures

:::note{title="Three byte ceilings, and they do not measure the same bytes"}
The two columns in the table are not interchangeable with each other. The
**bytes per result** column is the size at which the executor raises. The
**island ceiling** is what the size recommender bands against. Quoting one where
the other belongs is a mistake this codebase has shipped twice, both times while
correcting SQL Server.

A third ceiling sits outside the table:
[`MAX_PUBLISH_BYTES`](#size-constants), 5,242,880 bytes on the compiled
dashboard body. It applies on every engine in the table, including the four with
no execution-time byte cap, where it and the island ceiling are the only byte
limits there are.

**Do not read those thresholds as one axis.** They measure different bytes:

| Ceiling | Measures |
|---|---|
| bytes per result | the query result in its **row-major** form, as the database serializes it, before any encoding |
| `MAX_PUBLISH_BYTES` | the finished body, whose data island is **dictionary-columnar packed** |

A packing step several times smaller than the input sits between them, so 5,242,880
is **not** simply the tighter of the two. Measured on a board-shaped cube grown
until its row-major form crossed 8,000,000: the packed island landed at
**1,903,028** bytes, comfortably inside the 5,242,880 cap. On that dashboard the
executor is what refuses you, not the publish cap.

**Where the publish cap does bind first:**

- a dashboard whose **several inline datasets** sum toward it, which is the case
  the publish-time budget message is about;
- a body whose island is **not packed** at all: packing is off in
  [look mode](/reference/spec#look), and off for any dashboard carrying a
  `custom` tile;
- **look-mode markup** that is large in its own right, since your HTML counts
  against the same 5,242,880.

Otherwise, on an ordinary single-dataset dashboard built from `tiles`, expect the
per-engine result cap to be the one you meet.
:::

## Size constants

| Constant | Value | What it bounds |
|---|---|---|
| `MAX_PUBLISH_BYTES` | 5,242,880 | The compiled dashboard body, 5 MiB. Publish is refused past it. Inline data ships inside that body, in packed form, so this is not directly comparable to the per-engine result caps: see the note above. |
| `SLUG_MAX_LENGTH` | 64 | Characters in a dashboard slug. |
| `INLINE_MAX_ROWS` | 100,000 | Rows in one inline dataset result, on every engine except `mssql`. |
| `INLINE_MAX_BYTES` | 8,388,608 | The island ceiling, 8 MiB, on every engine except `mssql`. |
| `EXECUTOR_MAX_BYTES` | 8,000,000 | The serialized size at which the read-only executor raises, for `self` and `postgres`. |
| `MSSQL_INLINE_MAX_ROWS` | 5,000 | Rows in one inline dataset result on `mssql`. |
| `MSSQL_EXECUTOR_MAX_BYTES` | 2,000,000 | The serialized size at which the `mssql` executor raises. |
| `MSSQL_INLINE_MAX_BYTES` | 2,097,152 | The island ceiling on `mssql`, 2 MiB. |
| `LATTICE_MAX_CELLS` | 50,000 | Cells in one precomputed lattice, estimated from each dimension's declared cardinality. A lattice whose estimate is over this is refused at publish. |
| `MAX_DATASETS` | 8 | Datasets in one dashboard. |
| `PARQUET_DATASETS_MAX` | 2 | Parquet-backed datasets in one dashboard. |
| `FLAT_PARQUET_CEILING` | 268,435,456 | A Parquet object, 256 MiB, for a dashboard whose island carries the range-read capability tag. A spec publish always emits that tag when a Parquet dataset is present, so this is the ceiling in practice. |
| `EXTRACT_MAX_PARQUET_BYTES` | 134,217,728 | A Parquet object, 128 MiB, for an older island with no range-read tag, whose runtime downloads the whole file. |
| `MAX_EXTRACT_ROWS` | 50,000,000 | Rows in one Parquet extract. |
| `SEED_PROBE_MAX_ROWS` | 1,000 | Rows read from a Parquet-backed dataset at publish, to type its columns and prove the SQL runs. |
| `CUBE_VALIDATE_ECHO_ROWS` | 200 | Sample rows `validate_cube_sql` echoes back. |
| `CUBE_VALIDATE_ECHO_BYTES` | 8,192 | Bytes of that sample, whichever binds first. |
| `LIST_DEFAULT_LIMIT` | 50 | Dashboards per `list_dashboards` page by default. |
| `LIST_MAX_LIMIT` | 100 | Dashboards per `list_dashboards` page at most. |

The Parquet path applies only where the **Over the island ceiling** column above
says `Parquet`. On `self` and on `mssql` there is no extract path at all, so the
three Parquet constants never apply to either.

## Limits stated elsewhere

These are bounds a reader looks for here, but they belong to a surface with its
own contract page and are not repeated:

| Limit | Where it is stated |
|---|---|
| Structural caps: tiles, dimensions, measures, string lengths | [Dashboard spec (v1)](/reference/spec) |
| Per-tile `limit` ceilings | [Tile types](/reference/tiles) |
| Rate limits, version retention, upload and spec caps | [Shared rules](/reference/mcp-tools/conventions) |
| Schedule cadence multipliers | [Schedules](/concepts/schedules) |

## Check it worked

Ask your AI tool to validate a candidate cube against your connection. The reply
carries the exact row count and a size band. A `small` band means the result fits
inline; `big` means it is over the island ceiling and needs the Parquet path;
`extreme` means it is over the Parquet ceiling and the SQL has to change.