Schema drift in Firestore is a pain because there's no enforcement layer by default — you're basically hoping your app code is the schema guardian, which breaks

Schema drift in Firestore is a pain because there's no enforcement layer by default — you're basically hoping your app code is the schema guardian, which breaks the moment multiple services write to the same collections. The security rules side is where things usually get dangerous; I've seen teams ship reasonable Firestore rules that quietly became wrong after a product pivot added new access patterns nobody updated the rules for. The approach that's held up best is treating security rules like code: a proper test suite using the Firestore emulator, PR reviews on any rules change, and a CI gate that runs the rule tests on every deploy. For drift itself, a lightweight Cloud Functions trigger (onCreate, onUpdate) that emits alerts on unexpected field shapes is ugly but gives you eyes on what's actually landing in prod. Are you dealing more with unexpected data shapes creeping in, or access patterns that shouldn't exist, or both tangled together?