# Week1
Over the past week, I began working on extending Lighthouse's database layer to support a PostgreSQL backend. This is aimed at enabling a more robust, NFS-safe alternative to Redb and LevelDB.

**What I worked on**
* Started implementing a new `postgres_impl.rs` module using `sqlx` for async PostgreSQL access.
* Sketched out an experimental `AsyncKeyValueStore<E>` trait to support async-first databases like Postgres.
* Scaffolded out methods for `get_bytes`, `put_bytes`, and `do_atomatically` inside the Postgres implementation and connected it to a live Dockerized Postgres instance.
* Wrote an initial unit test using `sqlx::migrate!()` and `PgPool::connect()` to validate basic read/write behaviour against the schema.
* Push up a [draft PR](https://github.com/sigp/lighthouse/pull/7639) to get feedback on design and trait compatibility before diving into deeper integration.

**Design Considerations.**
Lighthouse's existing storage interface is fully synchronous. Since sqlx is async, i'm exploring two main strategies:
* Creating parallel async traits (like `AsyncKeyValueStore`) to avoid mixing async code in sync traits.
* Using feature flags (or boxed trait objects) to allow runtime / compile time switching between sync and async backends.

**Challenges**
* Balancing Lighthouse's existing backend abstration with the need for async I/O is proving nuanced.

**Next** **Steps**
* Wrap up the initial Postgres implementation.
* Finalize the async trait abstraction (`AsyncKeyValueStore<E>`) and think through its integration with BeaconNodeBackend.