The owner’s note on 2026-09-25 was blunt, and it was right. The keys were raw identity-provider subjects, snapshots lived inside recipe rows, and finding a user by email meant a scan.
Three candidates
Three layouts were drafted and each was loaded, read-only, from a copy of production so the owner could browse them in the console:
- Minimal change. Keep the keys, move snapshots out. Easiest, still unreadable.
- Hashed user prefix. Re-key every item under a short hash of the subject, so a user’s items sit together and the key gives nothing away. Snapshots in a history table. An email index as a global secondary index.
- Full single-table. Everything, including shopping lists and plans, under one key scheme with typed sort keys.
Option two was chosen: most of the benefit of three with a migration that can be checked item by item.
The work packages
The migration was split into work packages WP-H1 through WP-H2e: the new tables, dual-write, backfill, verification, the read switch, and finally the cut-over. Everything up to the cut-over is done.
Why it waits
The cut-over needs a data freeze: a short window where no writes land, so the backfill can be verified complete before reads switch. With outside users on the app, that window has to be announced. The freeze has not been scheduled yet.