# Week11
This week I've been deep in the weeds of Lighthouse's storage layer, exploring how to extend the Beacon Node database to support schema migrations with Redb.
The motivation: as we add new features and formats, we need a clean way to upgrade Redb file layouts without breaking existing users. My work begins the process of giving Redb a first-class migration path
## What's new
[PR/code](https://github.com/owanikin/lighthouse/commit/86fa5bfb71cf2a1f0930e229c07753687044e135)
- Wired Redb as a feature in beacon_chain: Added `redb = {"dep:redb"}` in cargo.toml so migrations can now be gated on Redb being enabled, just like LevelDB
- Abstracted migrations into `upgrade()`: Introduced upgrade() method in the KeyValueSotre trait and implemented it for BeaconNodeBackend. This lets us write `db.upgrage();` instead of scattering `#[cfg(feature = "redb")]` checks across migration scripts.
- Hooked Redb upgrade flow: Implemented `upgrade()` in `Redb<E>` which calls into underlying `redb::Database::upgrade()`. This makes migration call chain smooth →`HotColdDB → BeaconNodeBackend → Redb → redb::Database`
- Backend awareness in `HotColdDB`: Extended `HotColdDB` to track the active backend type (`LevelDb` vs `Redb`), so migrations can make runtime decisions based on which store is active.
- Refactored migration v29 script: Simplified the `upgrade_to_v29` and `downgrade_from_v29` functions to delegate directly to `db.upgrade()`, making redb upgrades explicit and other backends no-ops
## Why it matters
This sets the groundwork for backedn-specific schema migrations in Lighthouse. Redb, being, newer, needs careful handling so future changes (like schema bumps) don't leave users stranded. By giving Redb a clean upgrade path now, we ensure smoothe evolutions of Lighthouse's storage system later.
## What's next
- Clean up `upgrade()` to return `Result<(), Error>` (insteade of unit), so failed migrations can surface meaningful errors.
- Keep `leveldb` as the default backend, while making Redb a properly testable alternative.
- Add CI/tests to validate the `cargo test --features redb` execises the migration path.
This is a solid step towards making Redb a first-class storage backend in Lighthouse, with the same level of maturity as LevelDB migrations.