Skip to content

[Feature] Extend Database Migrations to NoSQL stores #4156

Description

@iancooper

No support for NoSQL stores in DB Migration tools

The DB Migration tools in Paramore.Brighter.BoxProvisioning covers SQL stores but not NoSQL stores like DynamoDB and MongoDB. These tend to have different approaches to schema, locking, etc., so they require a different approach.

  • Provisioning can use the existing process for a fresh install, but we should harmonize the interface as much as possible
  • It may be that if we do not need to alter index properties, and the payload is JSON, the issue is whether the application code can handle earlier versions, our migration code would have to load and re-save previous JSON entries
  • If we need to alter indexable properties, it may be beyond us, as it may require a new table and migrating all the existing entries

References

Evolve Your Amazon DynamoDb Tables
Dynamo Data Migrations
Can you change DynamoDb schemas?

Activity

  1. self-assigned this
    on May 27, 2026
  2. removed their assignment
    on May 29, 2026
  3. changed the title [-]Extend Database Migrations to NoSQL stores[/-] [+][Feature] Extend Database Migrations to NoSQL stores[/+] on Oct 15, 2026
  4. added and removed
    DraftThis is a work in progress
    on Oct 23, 2026
  5. iancooper commented on Oct 26, 2026

    @iancooper
    MemberAuthor

    Dependency from #4628 (spec 0039, ADR 0089): this issue has to land before the distributed outbox circuit breaker can support the NoSQL outboxes.

    The distributed breaker shares tripped topics through a small trip table that sits beside the outbox, in the same database, and is created through box provisioning (BoxType.TrippedTopics). ADR 0089 ships stores for MsSql, PostgreSql and MySql first. DynamoDB, MongoDb and Firestore users cannot use the breaker until:

    1. box provisioning can create a table or collection on those stores (this issue), and
    2. a trip store for each backend is written.

    A backend's store must provide:

    • an atomic per-topic upsert that keeps the later trip time and returns the prior one;
    • a marking of expired entries as ended that returns each marked entry to exactly one caller;
    • a read of the live entries;
    • durability across restarts;
    • a fixed number of operations per read, or a stated bound.

    For DynamoDB, ReturnValues = ALL_OLD gives the first. Its conditional updates are per item, so its read cost grows with the number of ended trips, and that backend's ADR has to state that bound.

    Sqlite and Spanner are different. They already have box provisioning, and have no distributed lock provider, so a multi-instance deployment there is not possible today anyway. They need only a trip store, not new provisioning.

    Until a backend ships, those users keep InMemoryOutboxCircuitBreaker, which in spec 0039 Phase 1 gains a maximum trip duration so a trip can no longer go stale.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions