# Week7 Over the past 2 weeks, I have been working on the implementing the missing support (methods) for Postgres backend, which are a core requirement for database operations in Lighthouse. ### Consistency Across Backends One of the main goals of this work has been to ensure that Postgres backend follows the same interface and patterns as LeveDB and ReDB. This will help avoid hidden bugs when switching backends, simplifying testing and making sure future maintenance is easier. However, as the rest of Lighthouse DB implemnetions is `sync` while postgres DB interactions are `async` - this raises a big problem! So we have two options, either maybe all db interactions async (which as pretty significant downstream effects for the rest of lighthouse) OR keep all the db interactions sync and use [tokios block_on](https://docs.rs/tokio/latest/tokio/runtime/struct.Handle.html#method.block_on) for any postgres async db interactions. Option 2, also requires us to have access to a runtime within the postgres db implementation and we could use [this](https://docs.rs/tokio/latest/tokio/runtime/struct.Handle.html#method.try_current) to do that. This is a lot harder than it sounds. Anyway, this is what I've implemented of it [here](https://github.com/sigp/lighthouse/pull/7685/commits/b77ca6dc8c71271b0ab1042145ba87d6868cbeb9), minimally, to make the test suite for other DB implementations to pass for postgres in an async mode. ### Next Steps Over the coming week(s), I will implement the support (methods) in full, do more unit tests, begin to do some integration tests and monitor how it handles real data, compared to LevelDB and ReDB.