Telemetry schema changes are inevitable: new sensors, renamed fields, unit corrections, derived metrics. If evolution is unmanaged, dashboards break silently and analytics lose trust.
1. Schema goals and constraints
Define what your schema must support:
- backward compatibility window
- low-bandwidth encoding options
- easy parsing on constrained devices
- clear unit and timestamp semantics
Optimization without explicit goals often creates long-term compatibility pain.
2. Version placement choices
Three common options:
- version in payload field
- version in topic path
- version in content-type metadata
For MQTT telemetry, payload field plus documented topic lineage is usually easiest to operate.
3. Compatibility rules
Set and publish rules, for example:
- additive optional fields are backward-compatible
- field type changes are breaking
- unit changes require new field or version bump
Rules should be machine-checked in CI.
4. Migration mechanics
When introducing a new schema:
- dual-write old and new for transition period
- validate parity in ingestion layer
- migrate consumers incrementally
Never force all consumers to switch simultaneously unless system is tiny.
5. Validation gates
Add schema validation at multiple points:
- device side before publish
- broker-adjacent ingestion service
- storage write boundary
Early rejection of invalid events protects downstream analytics.
6. Observability during rollout
Track rollout metrics:
- events by schema version
- parse failure rates by version
- consumer adoption progress
Without these metrics, migration status is mostly anecdotal.
7. Deprecation and retention policy
Define when old versions are retired and how long data remains queryable. Historical comparability often requires conversion layers or normalized views.
Deprecation without timeline causes permanent legacy burden.
8. Governance process
Schema changes need lightweight governance:
- proposal template
- compatibility impact review
- rollout plan and owner
- rollback plan
Even a small process avoids expensive downstream breakage.
Final note
Telemetry schema versioning is a product reliability concern, not only a data team concern. A deliberate evolution process keeps devices, pipelines, and analytics aligned over time.