Skip to main content
By default, each device gets its own schema review and materialization target. Registry coalescing lets many devices sharing the same table shape reuse one schema decision and one coalesced target.

​
When to use coalescing

Coalescing reduces operator toil: approve once, auto-approve subsequent devices with the same schema_hash.

​
How it works

  1. First device announces hash H for table telemetry_readings → registry review created.
  2. Operator approves with column actions at registry scope.
  3. Second device sends same hash H → device schema auto-approved, rows materialize to shared mirror.
  4. Physical table name pattern depends on the approved destination:
    • Telemetry: edge_ts_p{project8}_{table} or edge_ts_f{fleet8}_{table}
    • Relational/state: edge_state_p{project8}_{table} or edge_state_f{fleet8}_{table}

​
Policy configuration

Set coalescing mode at project level:
Body includes schema_coalescing_mode: none | project | fleet. Requires Idempotency-Key and manage-devices permission.

​
Registry HTTP routes (project scope)

Fleet-scoped equivalents exist under:
See API reference.

​
Consolidation

consolidate merges device-scoped mirrors into a coalesced mirror when migrating from none → project/fleet mode. Use during fleet standardization projects — coordinate with Golain support for large fleets.

​
platform-tui gap

Registry reviews and coalesced mirror management are HTTP API only today. The TUI covers per-device lineages and device-scoped schema reviews. Use curl, OpenAPI client, or automation against registry routes until TUI support lands.

​
Operator checklist (coalesced fleet)

  1. Set schema_coalescing_mode=fleet on project policy.
  2. Enroll first device → complete registry review (not just device review).
  3. Roll out identical schema to additional devices.
  4. Verify rows in coalesced mirror via GET .../coalesced-mirrors/{id}.
  5. Query with fleet-scoped filters (device_id column in mirror rows).