Deta Space Collections and Space Apps: Can Schema Migrations Roll Back Safely?

Question

Goal: Determine whether an application-level schema migration from a Deta Space App can be reversed in Deta Space Collections without corrupting document shapes or losing writes accepted after the migration starts.

Collections are schema-less, while Space Apps declare Collection access but provide no documented migration registry, transaction spanning documents or collections, or deploy-time rollback hook. A Space snapshot is a coarse rollback boundary: restoring it may discard intervening writes across the Space. Collection triggers are asynchronous, and concurrent app versions may read or write different document shapes.

This question applies to the currently documented Collections, Space Apps, and Node, Python, and Go SDK interfaces. The relevant verification boundary is a two-Collection test Space with concurrent app versions and trigger events; snapshot, trigger, and consistency semantics should be checked against the target Space release before relying on them.

Can a Space App coordinate a versioned backfill with a rollback that preserves writes accepted during migration? Does snapshot restore provide a usable compatibility boundary for two app versions? Can already-delivered trigger events be reconciled after a restore without assuming replay or suppression?

Tasadduq Burney · Answer

AnswerNo, a Space App cannot safely roll back a schema migration in Deta Space Collections without risking data loss or shape corruption.Likely explanationThe migration is applied by code changes only; Collections are schema-less, so a restored snapshot does not enforce the newer shape and may discard writes that introduced new fields. Snapshots are coarse rollback points and lose all writes after the snapshot, which can include backfill writes. Collection triggers fire asynchronously and are not transactional, so events that occurred before the restore cannot be automatically reconciled.Confirmed factsA Space App has no documented migration registry, versioned backfill API, or transaction that spans collections.Restoring a snapshot discards all writes that occurred after the snapshot, potentially removing writes accepted during the backfill.Collection triggers are asynchronous and fire on both old and new app versions, risking duplicate or missing processing after a restore.To determine if a safe rollback is possible you must verify that no writes were accepted after the snapshot was taken. If that condition holds, a versioned backfill that writes only to documents compatible with the older app version may allow a rollback without shape corruption.Missing diagnostic detail needed: Was the snapshot created before any migration-related writes were accepted? This determines whether the rollback can retain those writes.

Deta Space Collections and Space Apps: Can Schema Migrations Roll Back Safely?

1 answer

Answer

Likely explanation

Confirmed facts

Your perspective belongs here.

0 question comments