Changing configuration and associated risks
Changing beacon configuration after data has been written can have significant correctness and security implications. Some configuration parameters directly affect how beacons are derived and queried, and incorrect changes might result in incomplete query results or ambiguous semantics. Misconfiguration does not cause data loss—data remains accessible via Scan—but it might prevent Query operations from returning complete results.
Warning
Some configuration changes are effectively irreversible without rewriting data.
Irreversible changes
-
After the first item is written, the truncation length and beacon key must be treated as immutable.
-
Partition configuration must be monotonic; decreases are not supported.
-
Correcting these issues requires recomputing all affected beacons.
What can go wrong
-
Decreasing partition configuration (for example,
maximumNumberOfPartitions, defaultNumberOfPartitions, numberOfPartitions) can cause queries to miss items and make existingPartitionNumbervalues ambiguous. -
Changing the truncation length after writes might cause queries to return incomplete results.
-
Changing the beacon key invalidates all existing beacons.
Recommended guidance
-
Choose conservative truncation lengths and treat them as fixed.
-
Plan for partition growth up front and allow only increases over time.
-
Never change beacon keys without a full migration plan.
Pre-flight checklist
Before deployment, confirm:
-
The dataset is suitable for beacons.
-
Truncation length and partition growth are planned and documented.
-
Monitoring and alerting are in place for configuration changes.
