I am always curious to find the differences between managed databases on public clouds. Let’s consider for example innodb_flush_log_at_trx_commit, a key system variable for MySQL.

You cannot change it on Cloud SQL for MySQL (the managed service offered by Google) so you cannot make a durability/speed trade-off.

I can see only a few reasons for doing that:

• google makes it safer for you, you do not know enough. It is a managed service after all
• they modified the engine and cannot support it
• they forgot to expose it as a flag but it might be there in one of the next iterations
• you would pay for more resources to serve your traffic with the default value. Even if you do not need full ACID compliance

By comparison, you can change and set the value of innodb_flush_log_at_trx_commit on Amazon RDS or Azure Database for MySQL

A similar issue surface if you want to use utf8mb4 as a character set (4-Byte UTF-8 Unicode Encoding). The feedback on Cloud SQL is

Filter utf8mb4 strings out of your data.

What is the lesson here?

Before choosing one of the main providers to host your database as a managed service, double check that they support all the not default configuration you might have in place or you would like to use. This is extremely important in case of migration across different cloud providers: you do not want to figure out you have a blocker when you are half way through the process.