Thank you all for following up and sharing your experiences and suggestions and I'm sorry you ran into similar issues, @cartes. We have been discussing this and will put forth a concrete plan based on your suggestions and experiences.
Please do note that the database is not a stable interface and that this is not a supported way of accessing Central data. You can read more in this post and we will update documentation to make this clearer. As I described above, we are working on an API to request a database backup without needing direct database access. The analysis workflows we currently design for are based around periodic exports or connecting to the OData feed. If those do not satisfy your requirements, it would be good to learn more about your use case. For example, @dmenne has described wanting to look up specific entities he has collected data about rather than doing bulk analysis.
The docs say:
By default, the only things removed are:
- Containers for services defined in the Compose file
- Networks defined in the networks section of the Compose file
- The default network, if one is used
I see now how removing the container would lose the anonymous volume bindings but I think the docker-compose docs could make that clearer. I have made some suggestions on their end. For what it's worth as we figure out what action we will take, the volume should still be there and can be identified and reattached. I fully acknowledge this is very inconvenient.