Table Resources
Reference for table-resource CLI behavior, storage filters, and table-family
limits.
Quick Answer
Use breyta resources read <res://...> for the quickest compact preview/read path. Add --full only when the complete payload is required.
Use breyta resources table ... for the richer operational surface: query,
aggregate, export, import, single-cell edits, column-definition changes,
recompute, and materialized joins.
Storage Filters
Resource storage filters use normalized indexed storage fields rather than the
raw full object path:
--storage-backendmatches backend family such asgcs--storage-rootmatches the configured root such asreports/acme--path-prefixmatches the relative path under that root such as
exports/2026- broad text search can still match the full indexed
pathwhen you need raw
path or debug search
Table Command Notes
- dynamic enum columns are authored with
--enum-json - enum writes normalize to stable ids, while the web preview and
Copy Markdown
render configured names breyta resources table importaccepts either an existing table resource URI or a logical table name and creates named tables on first write- named-table
upsertimports must provide--key-fields;--index-fieldsseeds the initial promoted/index field set upsertdoes not delete rows omitted from a later write; use a run/batch key
or partition when a flow needs latest-snapshot reads- composite key lookups repeat
--key, for example
--key meeting-key=m1 --key agenda-item-number=1 - existing schema type hints coerce
boolean,number,date, and
timestampcolumns before write - text and mixed columns stay string-backed
- aggregate support includes grouped ordering, metric-local filters,
arg-max/arg-min,having, bucketed groups, boundedcollect-set,
percentile, andmedian
Table Family Limits
Key enforced limits for table families:
1500table resources (families) per workspace50_000live rows per concrete table inside a family200columns per table16promoted/index fields per table128partitions per family16partitions touched per write12selected partitions per query, aggregate, or export24selected partitions per preview, read, or schema call256max partition key bytes64 KBper cell256 KBmax row payload256 MBmax table size2 GBmax workspace table DB size1000rows per write or query page10000max query scan window viapage.offset + page.limit200max aggregate groups
Partitioned Families
- first-class partitioned table families are part of the model through
:persist {:type :table ... :partitioning ...}and the
breyta resources table ...surface - use a partitioned family when data naturally partitions and most reads/writes
stay within one partition or a small bounded subset - keep the family root as the schema and metadata owner
- select partition scope explicitly for query-like operations instead of relying
on implicit all-partitions scans - separate explicit tables are still useful when the data really represents
distinct datasets or lifecycles - if the workload mainly needs wide cross-partition scans, arbitrary joins, or
general database behavior, prefer a dedicated:dbstep and external
database or query backend