Mathieu Othacehe <othacehe@gnu.org> writes:

> At first I thought that all the performance issues we had were caused by
> unoptimized SQL queries. Turns out it was only half of the problem.
>
> As we have multiple processes accessing the database (cuirass,
> cuirass-web, cuirass-send-events and now remote-server), we are falling
> into the architecture model that is very badly supported by SQLite: many
> readers and many readers across several processes[1].
>
> I also noticed that SQLite doesn't handle I/O pressure on the hard drive
> the database is sitting on. I had to mount the database file on a tmpfs
> directory to get around this issue[2].
>
> Finally, SQLite doesn't offer any real monitoring solution, requires
> periodical vacuuming and is really hard to configure[3].
>
> As stated on SQLite website: "SQLite does not compete with client/server
> databases. SQLite competes with fopen()."
>
> I've been running Cuirass using a PostgreSQL database, and without any
> particular tuning everything works smooth, which makes me regret to have
> waited so long to leap the breach.
>
> Thanks for you interest,

Very interesting, thanks for sharing your experience.  Worth a blog post
in my opinion ;)

Cheers!