Ory is the largest open source community in the world for cloud software application security. We maintain advanced open source security software solving authentication, authorization, access control, application network security, and delegation. Ory implements a variety of industry and best-practice standards including OAuth 2.0 / OAuth 2.1, OpenID Connect, Zero Trust Networking, Google Zanzibar Policy Framework, FIDO2 U2F, WebAuthn, TOTP, and more.

Ory Community

Hi all! About the two database migrations marked as Breaking Change  <https://github.com/ory/hydra/blob/e973ffe04c34520f6f3ea3452bbfd954f307a6e1/persistence/sql/migrations/20201116133000_set_null_time.mysql.up.sql|[1]> <https://github.com/ory/hydra/blob/a8ca333bb65fe591d1795ce5b33760c97ff54d65/persistence/sql/migrations/20201110104000_drop_uq_oauth2.mysql.up.sql|[2]>, I have two questions:
1. do you have any approx benchmark on how it could take on MySQL on X amount of data?
2. are the migrations backward compatible with Hydra version &lt; `v1.9.0`? I want to be sure not to break old kube pods during the rolling update and/or trying to run the migration manually before the hydra update.

Please, does anyone have a clue to give me regarding at least point 2? :pray:

Do you have a staging environment? Even if you get the positive answer here it can still break.

Thanks for the answer <@U01QGLU1DNY>. That's the point. Manually testing on a dev/staging environment it's not so reliable imho. I would like to know if the migrations have been designed to be compatible with older application versions or not.