[o175]

The lazy migration design is clever for the common case, but I keep getting stuck on what happens when a migration isn't just "add a column." If you need to backfill a derived field or rebuild an index across a restructured table, some unlucky user's request becomes the one that absorbs thirty seconds of migration work instead of the usual milliseconds. And you can't really pre-migrate millions of idle databases either, since the whole point is they only wake on demand. Is there a pattern people are using here, like versioned read paths that serve old-schema data while migrating in the background, or is the practical answer just "don't write heavy migrations"?

[fastball]

You can pre-migrate if you want, just by hitting every actor with a request as soon as you deploy the change with a migration.

Personally I think the benefits of lazy outweigh the downside of that single 30s request, but to each their own.