So you’ve made the decision to build a Database-as-a-Service product (or something similar). As a result, you are making state and coordination your problem. Here are some things I’ve learned to keep in mind as you embark on this project, in no particular order (other than the first). This is a long one, so a table of contents is provided to skip around to the points that interest you.
As a relational-and-non-relational database management system-as-a-service (RaNRDBMSaaS) provider, your customers trust you with their data. Your golden rule, rule 0, first axiom - do not lose a customer’s data.
These are the table stakes of operating this product. So follow all the rules of backups (3-2-1, testing backups, continuous assurance of backup security and utility etc) and ensure you are checking for data corruption (e.g. using amcheck for PostgreSQL, mysqlcheck for MySQL). Your business will simply cease to exist if you do not meet the hexad.
A notable part of this is control. Customers always own their data, and should be able to both import and export their data from your product as smoothly as possible - do not hold data hostage. You want your customer to stick with your product because of how good it is, not because it is impossible to export. This level of control may or may not extend to how the data is encrypted, such as using customer managed keys.