Waku Store Cache: PostgreSQL implementation

[jm-clius]

Background

This forms part of a series of issues raised as output of the recent Status client offsite.

Waku Store is a query protocol for client nodes to retrieve historical messages from a cache on a service node.
Status Client teams have identified Store (both the protocol and the cache) as particularly central to their application. Status applications pose a significant performance requirement on the store cache implementations (rate of messages inserted, as well as rate and complexity of history queries). Most of the dogfooding issues in Waku v2 integration into Status apps have been related to the store.

What has been done

There is existing work on both the protocol and the backend cache implementation to improve query performance.

In the short term the Store Roadmap captures the work that has been done and is in progress to rework the protocol, improve query composition, and increase reliability. Within nwaku, the store cache now has a pluggable interface to allow for future store implementations.

Problem

However, the very high rate of message insertions and concurrent store queries shows the inadequacy of the only existing store cache implementation in SQLite. SQLite generally does not scale, has no built-in redundancy mechanisms, does not process queries in parallel, etc.

We decided to move to a PostgreSQLl implementation as a natural next step. This technology is also familiar to many Waku-focused contributors within the Status client teams, as this has been the implementation for the Waku v1 mailservers.

This implementation will likely be required both in nwaku (which forms most of the network infrastructure) and go-waku (since Desktop clients may want to provide store services themselves).

[Ivansete-status]

We will cover all the implementation progress in the next issue
waku-org/nwaku#1888