Replicated founder here. Great question. The main concern most people have when considering putting a database in a container is around data loss or corruption. (i.e. What happens if the instance disappears and the data was stored on an ephemeral disk?) We have a couple of features to help with this:
Replicated allows for the end customer to choose if they want to run the containerized version of the database, or provide their own instance of it (not in a container) and simply provide a connection string so the application can use that instance. Generally this is exposed as a checkbox on the settings page, and doesn't require a lot of configuration.
If the end customer decides to install with the containerized version of the database, they can choose to run the database container on a specific instance (or instances) and control the host path of the volume mount(s). The idea here is that they will store the data on an EBS volume, network attached storage etc.
We also have a feature that allows for snapshots and restores to help in the scenario where the database was store on the local instance and there was a hardware failure or corruption.
These features work out of the box, without a lot of effort from the software vendor to configure.
After reading your docs and install scripts, I think another option for us is to run the database directly on the client's host. That is, as part of our installation guide, we'd say Step1:Install Replicated, Step2:Install DB, Step3:Run setup. This might be easier in a trusted environment where containers can be started on the host network. This approach has potential issues with replication, encryption, upgradeability, etc, but those are normal infrastructure challenges and have nothing to do with Replicated.
Replicated allows for the end customer to choose if they want to run the containerized version of the database, or provide their own instance of it (not in a container) and simply provide a connection string so the application can use that instance. Generally this is exposed as a checkbox on the settings page, and doesn't require a lot of configuration.
If the end customer decides to install with the containerized version of the database, they can choose to run the database container on a specific instance (or instances) and control the host path of the volume mount(s). The idea here is that they will store the data on an EBS volume, network attached storage etc.
We also have a feature that allows for snapshots and restores to help in the scenario where the database was store on the local instance and there was a hardware failure or corruption.
These features work out of the box, without a lot of effort from the software vendor to configure.