In the previous post , I introduced a real migration scenario where a client, in the process of modernising their application, made an interesting architectural choice - to run their MySQL database inside a container alongside the rest of their services. At first glance, the approach made sense. The entire application was being redesigned around containers. Keeping everything consistent felt clean and intuitive. But as we explored in the first post, databases don’t behave like the rest of your application. They are stateful, performance-sensitive, and operationally demanding in ways that don’t always align with container-first design patterns. The real challenge wasn’t whether the database could run in a container. It was whether it should, especially for a production database, and when there are other options available that may be better suited to the nature of database workloads. And that is where the conversation shifted.…