# 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.