<div dir="ltr"><div></div><div>I'll do some research to evaluate my options. So far I have:<br><br>Homegrown implementation on top of some DB (Riak/Postgres/Mongo...)<br><a href="https://github.com/agentm/project-m36" target="_blank">https://github.com/agentm/proj<wbr>ect-m36</a><br><a href="https://hackage.haskell.org/package/filestore" target="_blank">https://hackage.haskell.org/<wbr>package/filestore</a><br></div><div><br></div><div class="gmail_extra"><div class="gmail_quote">Thanks for the answers!<br><br>On Fri, Dec 23, 2016 at 8:07 PM, Ertugrul Söylemez <span dir="ltr"><<a href="mailto:esz@posteo.de" target="_blank">esz@posteo.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>>>   * 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>
><br>
> I assume that some sort of structural sharing is needed once the<br>
> collections grow above a certain size. Also some support for caching<br>
> would be nice.<br>
<br>
</span>Yeah, sharing could improve disk usage and cache utilisation.  I'm not<br>
aware of any DBMS-side sharing features in systems I have used<br>
(PostgreSQL and SQLite mainly).  The usual way to get sharing in<br>
relational systems is to normalise the schema.  That also allows you to<br>
use domain-specific knowledge to get even better sharing.<br>
<br>
Caching is of course supported, at least by PostgreSQL.  It aims to keep<br>
as much of the database in memory as possible (or as you tell it to).<br>
</blockquote></div><br></div></div>