The state I meant is the state which is given to the update function in the Elm app. I was describing the perspective of the App Developer, who writes his Elm app which a top level update function. In the projects I have seen so far, it was OK for clients in the front end to reset their state, because in this case the client can get the (relevant portion of) the last state from the backend. In the end, it was the job of the backend to keep the records. That is why I mentioned this as what is different between back end work and front end.
Since you mention in-memory storage and disk storage, a quick look on the implementation side: Of course, at the time I start the backend, I need to pick a store for persisting the app state. For now, I am using a plain classic file system API to do this. Having the Implementation reach down to the file system is what prevents the loss of the app state when an unexpected shutdown happens. This implementation is part of the hosting framework, the Elm app does not know about this.
Why is the state part more complicated? Is that database outside of the Elm Model? If so, why? Did you encounter problems when keeping the database in the Elm Model?