Hello Pierre,
> - Why is it called "Cuirass"? :p No idea, you would have to ask Mathieu Lirzin about it! > - Why the move to PostgreSQL? 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, Mathieu [1]: https://softwareengineering.stackexchange.com/questions/340550/why-are-concurrent-writes-not-allowed-on-an-sqlite-database [2]: https://issues.guix.gnu.org/43850 [3]: https://wiki.mozilla.org/Performance/Avoid_SQLite_In_Your_Next_Firefox_Feature