Docs
Reference

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-backend matches backend family such as gcs
  • --storage-root matches the configured root such as reports/acme
  • --path-prefix matches the relative path under that root such as
    exports/2026
  • broad text search can still match the full indexed path when 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 import accepts either an existing table resource URI or a logical table name and creates named tables on first write
  • named-table upsert imports must provide --key-fields; --index-fields seeds the initial promoted/index field set
  • upsert does 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
    timestamp columns before write
  • text and mixed columns stay string-backed
  • aggregate support includes grouped ordering, metric-local filters,
    arg-max / arg-min, having, bucketed groups, bounded collect-set,
    percentile, and median

Table Family Limits

Key enforced limits for table families:

  • 1500 table resources (families) per workspace
  • 50_000 live rows per concrete table inside a family
  • 200 columns per table
  • 16 promoted/index fields per table
  • 128 partitions per family
  • 16 partitions touched per write
  • 12 selected partitions per query, aggregate, or export
  • 24 selected partitions per preview, read, or schema call
  • 256 max partition key bytes
  • 64 KB per cell
  • 256 KB max row payload
  • 256 MB max table size
  • 2 GB max workspace table DB size
  • 1000 rows per write or query page
  • 10000 max query scan window via page.offset + page.limit
  • 200 max 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 :db step and external
    database or query backend

Related

As of May 27, 2026