[luuuuk]

Thanks for your input! As future features require continuous syncing between calendar data and the database, SQLite is not really an option.

We chose MySQL based on the following requirements:

- It should be easy to write data to a database created by us, or hosted (on-premise) by a customer due to the sensitive nature of the data (which excludes Google Cloud Spanner and Amazon Aurora)

- As the purpose of this data is analyzed, the DB should be compatible with most BI tools (which excludes SQLite)

- There should be no vendor lock-in

- Due to the analysis purpose of this tool, we prefer a database that focusses on read performance vs write performance (MySQL > PostgreSQL)

- The Calendar Events table can grow long and we don't anticipate it getting wide, which favors row-based databases vs column-based databases (MySQL > Redshift)

- I personally use the WITH and WITH RECURSIVE statements a TON when doing analysis which originally excluded MySQL, but with the launch of MySQL 8, that no longer was an issue.

- We can easily build export functionality to SQLite

For all these reasons, we thought (and think) that MySQL 8 fits the use case quite well and we can relatively easily support other RDBMS databases if needed. Would love to hear your thoughts!

[paulryanrogers]

> - There should be no vendor lock-in

Then why only support MySQL?

[luuuuk]

MySQL seemed a good start and we'll roll out more options upon request, but we first want to see some engagement and get some feedback before investing in that.

To test out how hard it would be to support another DB type, we already have a branch working that writes to a Postgres DB, which was a minor adjustment. So: MySQL for now, but we are writing our code to easily support other DBs if needed.

There are migration tools available for almost any database type from MySQL