This is a simple application and most likely always will be.
Although support for multiple databases seems useful, SQLite provides more than adequate performance and functionality and removing support for Postgres would simplify the code base and the CI/CD implementation.
SQLite provides all the functionality we need. Backups can be completed via file copy of the single file database, or programmatically. And the docker container can map an external volume to the container's file system for persistence.
SQLite does have a performance issue with write-heavy workloads. It obtains a lock on the whole database during writes. But any writes to the database that we have would be milliseconds in length and infrequent, so that shouldn't be an issue.
Are there any counter arguments to this?
This is a simple application and most likely always will be.
Although support for multiple databases seems useful, SQLite provides more than adequate performance and functionality and removing support for Postgres would simplify the code base and the CI/CD implementation.
SQLite provides all the functionality we need. Backups can be completed via file copy of the single file database, or programmatically. And the docker container can map an external volume to the container's file system for persistence.
SQLite does have a performance issue with write-heavy workloads. It obtains a lock on the whole database during writes. But any writes to the database that we have would be milliseconds in length and infrequent, so that shouldn't be an issue.
Are there any counter arguments to this?