<div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  * Would using a snapshot-based revision control system like Git be an<br>
    option?  If yes, you could use the [filestore] library.<br></blockquote></span><div>It's not exactly what I had in mind but I'll think about it.<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  * Another option is to run an insertion-only relational model on<br>
    really any database system you want like PostgreSQL.  There is<br>
    nothing about preserving history that needs special handling to be<br>
    efficient.<br></blockquote></span><div>I assume that some sort  of structural sharing is needed once the collections grow above a certain size. Also some support for caching would be nice.<br><br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  * Yet another option is to model your application state with history<br>
    and use [acid-state].  However, acid-state only makes an in-memory<br>
    Haskell value (the "database") persistent with ACID guarantees.  If<br>
    you mostly work with the current state, keeping the whole history in<br>
    memory all the time would be a waste.  Therefore this option may be<br>
    less useful.<br></blockquote></span><div>The database will probably grow bigger than the memory so this is not an option.<br></div></div><br></div></div>
</div>...and thanks for the pointers<br></div>