I don't think anyone advocates for generating based on a production database connection. I can only tell you how I've used jOOQ, using the same general setup fo

I don't think anyone advocates for generating based on a production database connection. I can only tell you how I've used jOOQ, using the same general setup for 6 years despite job changes. I wrote the original Gradle plugins for jOOQ and Flyway, the latter being a migration tool. These were then contributed back and I use the official variants now. I write SQL migrations for H2, an in-memory db. This is used by the build tool to code generate prior to compilation. It is also used by unit tests, when the Postgres queries can be emulated (majority of the time). The Postgres migrations are written separately, with similar code but minor dialect differences. That might be less duplicated (but trivial) work if I used LiquiBase instead of Flyway. When the application starts the migrations are run. Someday I might drop H2 for a containerized Postgres, especially if they add in-memory support for faster testing. This would avoid some codegen differences, like jsonb or (soon to be released) enum support. The work setting things up wasn't too bad. It was more when I originally started, since I had to build part of the ecosystem. But repeating the process elsewhere has been straightforward. It definitely pays off and is a joy to use day to day.