"- perform schema changes in a way that won’t break existing code (e.g., temporarily allowing new non-nullable columns to be NULL). - deploy code that works with both the old and new schema simultaneously, populating any new rows according to the new schema. - perform a data migration that backfills any old data correctly, and updates all constraints properly. - deploy code that only expects to see the new schema."

That sounds a lot like transactional schema updates in Firebird to me. Plus being careful about how the app handles the data. Schema updates in Firebird are essentially instantaneous, with the row updates performed lazily (although if you need it, a SELECT COUNT(*) will force an update of all rows immediately).