The SQLite database is hard to manage in production

[pietroalbini]

Crater currently relies on a single SQLite database for all its storage needs, but that's starting to be problematic in production:

• The database keeps growing, as we store all the logs on it and we don't actually remove them once an experiment finishes. This causes the database to reach tens of gigabytes of size, which on an EBS volume slows down the performance of the DB.
• The big and frequently accessed SQLite database prevents us from moving the Crater server on ECS, as storing the database on EFS would either be too expensive (when provisioning IOPS) or extremely slow (as queries would need to do network calls and I guess we would quickly run out of the burst IOPS).

The short term solution is to change Crater to proactively delete data (and possibly run VACUUM, even though that's been really slow in the past with our data size), but in the long term it'd be nice to migrate to PostgreSQL so that we can deploy Crater to ECS.

[Mark-Simulacrum]

We now proactively delete logs, but we still have a fairly large SQLite database.