That would work. The internal consistency will be at least once and you do de-duplication to handle message reliability through the database then. In other words, you need to uniquely identify each message to ensure idempotency since you will have duplicate writes of the same message to the database.

Just need to make sure to not mess up causal ordering between events because of out of order retries, if such things are important for your application.

Reading sequentially can be hard here, especially depending on throughput and how well you can or can't shard (e.g. how wide is the radius of possible side effects).

E.g. what if one event is something like "credit here, debit there" - you need to process it sequentially for both sides!