Skip to content

Database migration schema #341

Description

@Leon0412

🔖 Enhancement description

  • Non-destructive / Seamless schema migrations: Changing an attribute (like its type or format) should not drop the column and wipe existing data.
  • Atomic rollbacks: If an error occurs while applying schema changes via the CLI, the process should roll back to the last working state entirely, rather than leaving the database schema in a broken or partially updated state.

🎤 Pitch

In my opinion, the current “migration” via the Appwrite CLI and “appwrite.config.json” isn't really a migration at all.

The biggest problem: A single change to an existing attribute automatically leads to data loss, which is extremely critical in a production environment. And having to write a separate script for something like this isn’t worth the effort for such a basic task, in my opinion.

While this might be acceptable for side projects or early MVP stages, it becomes a massive deal-breaker when deciding whether to scale a SaaS product with Appwrite.

Furthermore, the lack of atomic rollbacks means if a CLI push fails halfway through, the schema doesn't revert to its last known good configuration, it simply breaks, leaving the database in an inconsistent state.

Feel free to correct me if I'm wrong.

👀 Have you spent some time to check if this issue has been raised before?

  • I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions