Limits

Lunora's design choices are driven by Cloudflare's per-primitive limits. Knowing these numbers helps you predict when to opt into .shardBy() or .global().

Durable Objects

Statement limits (Durable Objects and D1)

These are the ones that surprise people, because they are set by the Workers runtime rather than by SQLite, and they are far below SQLite's own defaults. D1 runs the same build, so both engines share them. Cross one and the statement fails at runtime with SQLITE_ERROR; it does not merely run slower.

Lunora handles most of these for you. Its generated SQL nests compound SELECTs five at a time, binds a long in list as a single JSON parameter, chunks multi-row INSERTs, and compiles contains to a position function rather than a LIKE pattern, so an id probe, a wide where … in, or a 50-character search term does not hit a wall as your schema grows.

Two are yours to respect, because no rewrite can absorb them:

• A document over 2 MB cannot be stored. Keep large payloads in R2 (@lunora/storage) and put a reference on the row. Note the limit is on the stored bytes, which are UTF-8: multi-byte text (CJK, emoji) costs up to 3× its character count, and v.bigint() / v.bytes() columns are stored twice on a shard-local table.
• A .global() table over 100 columns cannot be created. Split it, or move the extra fields into one object field.

D1

R2

Workers

Queues

Pipelines

send accepts one record or an array and forwards the array as a single ingestion call, so the 5 MB ceiling is a property of what you pass it. Nothing measures it locally (the byte count would mean serializing every record twice on an egress path), so a batch past the limit is rejected by Cloudflare rather than by Lunora. Split large batches across calls.

Workers AI + Vectorize

The ceiling covers the whole metadata object (chunk text, Lunora's bookkeeping keys, and any metadata you attach), so defineRag checks it in two places.

At index time it measures the serialized metadata of each chunk and refuses one that would not fit, naming what pushed it over. This is the check that holds: chunkSize counts characters while the ceiling counts bytes, so multibyte text costs up to three bytes each, and your own metadata is not known until a document is indexed.

When the RAG is defined it also rejects a chunkSize that could not fit whatever the ceiling allows, so an unworkable config fails at startup rather than on every upsert. That earlier check applies only where Lunora stores chunk text in the vector's metadata: a textStore keeps the text out entirely, and a custom chunk splitter makes chunkSize inert, so neither is checked.

Workers KV

Workflows

Containers

Requires the Workers Paid plan. Images must be linux/amd64.

Billing is active-CPU based: instances scale to zero on sleepAfter and cost nothing idle. Egress is billed (~$0.025/GB NA+EU, more elsewhere), unlike R2, which is free. See the Containers pricing docs.

When Lunora warns you

The Studio's Advisors pages carry the limit warnings, alongside the rest of the schema and performance lints:

Each fires with runway, because the remediation is a design change (split a table, narrow a read, re-key a shard) and that is not something you can act on in the request that fails.

The statement limits above are different in kind: there is no warning band, because there is no gradual degradation to warn about. A statement either fits or it raises SQLITE_ERROR. Where Lunora can keep you under one it does so silently; where it cannot (the 2 MB document, the 100-column table) it raises an error naming the limit and what to do instead.