Martin Stewart has talked with Mario about this and he’s put together a draft 
describing what data guarantees Lamdera provides.
# How Backend Persistence Works in Lamdera
Lamdera apps provide persistence by combining a few architectural properties:
Write-Ahead-Log (WAL): Every message is persisted to an ACID data store (PostgreSQL) before it gets processed. [⇒ TCR]
The Elm Architecture (TEA) […] [⇒ The Elm-Pages Architecture]
This combination allows us to have:
Persistence: because the backend state is entirely derived from messages, persisted messages mean a persisted backend state. page
Point-in-Time Recovery: replaying up to a specific message means recovering the backend state as at that point in time, meaning Lamdera apps retain history of every single backend state transition.
In-memory: The prior two points mean the backend state can live entirely in memory, without worrying about persistence or serialisation, leading to
* The highest possible performance on retrieval and insertion in application code: nominally 1-2 orders of magnitude faster than an external data store * Drastically reduced code complexity within applications: – No connectivity or pooling code – No separate schema & migration management & synchronisation – No data serialisation and disparate type mapping in/out of SQL queries
As a result Lamdera apps demonstrate as low as microsecond latency on Message handling.
[…]