Skip to content

Zero-downtime schema migrations using RediSearch aliases #773

@abrookins

Description

@abrookins

Summary

Add support for zero-downtime schema migrations using RediSearch index aliases instead of the current DROP+CREATE approach.

Problem

The current migration system (Migrator.run()) detects schema changes and performs:

  1. FT.DROPINDEX on the existing index
  2. FT.CREATE with the new schema

This causes downtime because queries fail while the index is being recreated and data is being reindexed.

Proposed Solution

Use RediSearch aliases (FT.ALIASADD, FT.ALIASUPDATE) to enable atomic index switching:

Index Naming Convention

Real index:  {prefix}:{model}:index:v1, {prefix}:{model}:index:v2, ...
Alias:       {prefix}:{model}:index  (what queries use)

Migration Flow

  1. Create new versioned index (e.g., idx:Product:v2) with updated schema
  2. Reindex/copy documents to new index (queries continue hitting v1 via alias)
  3. Atomically switch alias: FT.ALIASUPDATE idx:Product idx:Product:v2
  4. Drop old index idx:Product:v1

Implementation Requirements

  1. Version tracking - Store current version in Redis key (e.g., {prefix}:{model}:index:version)

  2. Initial setup - First migration creates v1 index and adds alias pointing to it

  3. Model queries - No change needed; already use Meta.index_name which becomes the alias

  4. New migration commands:

    • om migrate run --zero-downtime - Use alias-based migration
    • om migrate status - Show current index version and alias target
  5. Background reindexing - Copy documents from old index to new (may need batching for large datasets)

Key Redis Commands

FT.ALIASADD <alias> <index>      # Create alias (first time)
FT.ALIASUPDATE <alias> <index>   # Atomic switch to new index
FT.ALIASDEL <alias>              # Delete alias

Benefits

  • Zero downtime during schema migrations
  • Queries continue working throughout migration
  • Atomic switchover (no partial state)
  • Easy rollback (switch alias back to previous version)

Considerations

  • Increased Redis memory during migration (two indexes exist temporarily)
  • Reindexing time depends on dataset size
  • Need to handle concurrent writes during migration

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions