@spencer I don't get this. It's not Grail's fault that SpringLoaded is not supported anymore, and wouldn't you have the exact same problem with Spring Boot? Grails is essentially a Spring Boot app with convention over configuration and since Grails 4 some tie-ins to Micronaut for performance and taking advantage of what Micronaut has. So in my experience, if you don't let your app get too big before breaking up into services/microservices the start-up times are ok, so I would be interested in what you would term a "real" database, and what startup times are you consider to be unacceptable? Also, what would be the cold startup time including compilation, vs restarting time? In a previous company I worked which had a mega monolithic, about 6 projects 50k to 150k groovy lines of code(loc), with a 750K loc core, and over 2000 domains in another sub-project shared among the 6 projects, has a cold startup time of 8 to 12 min depending on the app, and a 4 to 5 min restart. Those times were reflective of the architecture of having that huge common core, and many files over 4k loc(Groovy compilation slows down exponentially after 4k loc). Gorm/Hibernate contributed some to the startup time because of its runtime/reflection-based nature which Spring also has, so in turn Grails has those same issues. At that company, I did try out Jrebel but found it slowed down things by 2x again because of the architecture and size of the project. One thing we did notice is that over the team both memory and CPU could have a dramatic impact on compilation/runtime, where some developers would see a 2 to 3x slow down compared to my numbers, being on a machine with a recent processor and plenty of memory. I also tried out the HotSwap Agent but didn't have much luck with that project. I have heard other people having luck with it. Maybe Grails, Spring, and Java collectively should invest in that project, if hot-swapping is that big of a deal. However, industry-wide there was a push toward microservices, which because of size didn't have the same startup issues. To do any development in that project I would do things differently, like setting breakpoints and hammering out code in Intellijs expression editor before putting it in the code, and restarting once just to double check the code worked. Also if I could avoid touching the common code base all the better because it took most of the compilation time. Eventually, that company will have to take on the unenviable task of breaking up the code into smaller projects, and if they go the services/microservices route maybe they will use a different framework for that task, as they would have the option. However, they would like any other company to have to weigh the trade-offs, of what they would lose, convention over configuration, plugins, and more rewriting. I wouldn't suggest a switch to Python Django just to have hot reloading though as that would be a huge shift and could cause higher turnover for those who don't want to learn Python. Not that learning Python is terribly hard, but I know that some developers would opt to find another JVM-based job over learning it. The other options that I know of would be Micronaut or Quarkus. Both, you would lose the Convention over configuration and plugins, and with Quarkus I think you would lose Groovy support. Anyway, just my thoughts, and I have to get to work, which at my current job is on Micronaut. However, I still have a fondness for Grails and think it has plenty of room to grow.