Limits

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	Parquet

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 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.

What each ceiling measures

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	3	Parquet-backed datasets in one dashboard.
DASHBOARD_PARQUET_BUDGET_BYTES	805,306,368	All of one dashboard's Parquet objects together, 768 MiB, across a single refresh. Separate from the per-object ceiling below: that one bounds what the extractor writes in one go, this one bounds what a viewer's browser has to hold.
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	18,000,000	Rows in one Parquet extract, per dataset. Derived from the 300s CPU budget one invocation gets, and each Parquet dataset now gets its own invocation, so the whole budget is one dataset's to spend.
FILE_UPLOAD_MAX_BYTES	95,000,000	The largest CSV or Excel file one upload accepts, 95 MB. Refused before anything is sent when the upload declares its size, and at the PUT otherwise.
SEED_PROBE_MAX_ROWS	1,000	Rows read from a Parquet-backed dataset at publish, to type its columns and prove the SQL runs.
SERVED_ANSWER_CELL_CEILING	110,000	Cells in one answer the served query tier returns, rows times columns. Past it the answer is refused, never truncated.
SERVED_ANSWER_CELL_WARNING_POINT	50,000	Cells at which the app warns you that a table tile is heading for the ceiling above. It refuses nothing.
ENTITLEMENT_PARTITION_CARDINALITY_MAX	100	Distinct values of a row-level-security key above which the extractor stops laying the data out one directory per value. It refuses nothing: it changes a default, and it is what a publish-time warning compares against.
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 there is no extract path at all, so the three Parquet constants never apply to it.

FILE_UPLOAD_MAX_BYTES is the only row here that bounds a file you send us rather than something a query produces, and it is a current value rather than a property of the architecture. It is the whole of the transport: there is no multipart or chunked upload, so a file over it cannot be sent in pieces and the remedy is to split the data across several files, each its own upload. An uploaded-file dashboard keeps its data with Dashies and is answered when a reader opens the page, so SERVED_ANSWER_CELL_CEILING and SERVED_ANSWER_CELL_WARNING_POINT bound what any one of its tiles may get back, exactly as they do for a warehouse dashboard. See Build a dashboard from a file.

SERVED_ANSWER_CELL_CEILING and SERVED_ANSWER_CELL_WARNING_POINT are a pair and only the first of them refuses anything. A dashboard whose data is served rather than shipped inside the file answers each tile from a query service, and that service measures an answer in cells: its rows times its columns. Past SERVED_ANSWER_CELL_CEILING it refuses the answer rather than returning a shorter one, so a tile that asks for too much shows a message and no numbers.

SERVED_ANSWER_CELL_WARNING_POINT is where the app tells you that is coming. It sits strictly below the ceiling, it refuses nothing, and the quantity it measures is the same product: a table tile's columns times the smaller of its declared row limit and the rows its dataset actually holds. It never fires on columns alone or on rows alone, because neither one predicts the product.

ENTITLEMENT_PARTITION_CARDINALITY_MAX is not a ceiling either, and it is the only row here that changes how your data is stored rather than what a query may return. A dashboard with row-level security filters by one column, and Dashies can either write one folder per value of that column, so a viewer's query opens only their own folder, or write the rows sorted by it so a query skips most of the file. The first is faster for one viewer and slower for a query that spans everybody.

Past about a hundred values the first layout stops paying, and the reason is about how Dashies writes rather than about your data: past that point the writer stops keeping one file open per folder and starts splitting a folder across several files, so a dashboard pays several files per value instead of one. Above this figure Dashies picks the sorted layout by default. If you asked for the folder layout anyway you get it, with a warning, and nothing is refused.

Both are current values, not properties of the architecture. The ceiling is today's admitted cell count at the one answer shape that has been measured; the warning point is derived from a paint measurement of how long a table of a given size takes to draw. mcp/worker/cube-caps.ts is the file that decides both and carries both derivations, and the guard that keeps this page honest reads them from there.

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)
Per-tile limit ceilings	Tile types
Rate limits, version retention, upload and spec caps	Shared rules
Schedule cadence multipliers	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.