A capability stays maintainable only when the team can explain every state, retry, and piece of residual data—not merely show one successful run. IndexedDB schema changes run in an upgrade transaction blocked by old connections. Large rewrites inside upgrade lock the database and may be terminated.
Data design covers atomic writes, concurrent access, schema migration, crash recovery, and cleanup. One successful save says nothing about power loss, full storage, or reopening with an older version.
Questions the design must answer
This capability crosses clients, networks, and servers, so a local optimization can create a system failure. Decisions must constrain both endpoints, persisted truth, and operating budgets together.
- Upgrade creates stores, indexes, and migration markers only; post-open batches persist a cursor, and BroadcastChannel asks old tabs to close connections.
- Define success, degraded, cancelled, and failed terminal states before UI, storage, and metrics consume the same state.
- Ship conservative defaults, server-side ceilings, and a rollout switch instead of trusting browser-provided numbers as resource budgets.
The delivery standard for IndexedDB Schema Migrations That Survive Interrupted Upgrades is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
Edge cases are part of the feature
Production failures often appear when two individually valid actions overlap. Inspect stale messages, duplicate effects, exhausted resources, and mixed versions instead of patching only the current stack frame.
- New code assuming migration completion reads mixed records, while an older app can write data the upgraded schema cannot interpret.
- A boolean failure cannot distinguish retryable, user-action, and permanent refusal, producing an endless loop.
- An untested fallback receives all traffic during a primary failure and becomes the slower, more expensive bottleneck.
Prove that it works with evidence
Do not stop verification when the final action succeeds. Count side effects, measure wait time, inspect privacy, and prove the next run begins from a clean baseline.
- Close during every batch and versionchange, retain an old tab, and roll back app code; verify reopen, continuation, and compatibility messaging.
- Race refresh, cancel, timeout, and remote completion in one scheduling window; assert one terminal state and one side effect.
- Use fault injection to prove alerts precede user reports and operators can locate the failing phase from bounded evidence.
A capability becomes maintainable when it degrades safely, repetition adds no side effects, and its signals reveal a fault before user reports do.