Hey there, back with another few questions. 😇 I am planning the upgrade from

supertokens-core

v3.16.2

to

v4.0.0

and I have a few questions around the database changes for the

emailpassword_users

and

thirdparty_users

table: Why did you choose

VARCHAR(256)

and

VARCHAR(128)

over just

TEXT

? The latter would have required no database migration and would not require a database migration in the future if the value changes again. Is it safe for me to use

TEXT

instead of

VARCHAR(256)

- or does

supertokens-core

do some kind of database schema validation? How did you manage to roll this out in production? In my current understanding it is not possible to apply this migration without locking the full database table and rewriting every single row. Wouldn't it been smarter (and also less "breaking") to follow this strategy: 1. Add a new columns "thirdparty_users"."third_party_user_id_new" and "emailpassword_users"."password_hash_new" 2. Run a script during outside of a migration/lock that copies the values from the old column to the new column 3. Write the super tokens code in a way that it can deal with both the old and new columns for the duration of the copy from old to new column period Right now, for us running the migration will probably not take longer than a few seconds - however, I am concerned that in the future additional breaking database changes will make it harder for us to migrate to the latest versions. Since you probably have much more users running on your hosted solution, I am especially curious on any insights on how you manged this (of course only if it is possible to share that information)!

> Why did you choose VARCHAR(256) and VARCHAR(128) over just TEXT? The latter would have required no database migration and would not require a database migration in the future if the value changes again. Is it safe for me to use TEXT instead of VARCHAR(256) - or does supertokens-core do some kind of database schema validation? Making TEXT a part of the primary key is not the best idea. You don't need to make these changes though.. things will still work if you just keep the older length. > Since you probably have much more users running on your hosted solution, I am especially curious on any insights on how you manged this (of course only if it is possible to share that information)! Just running the command mentioned in the changelog works well even for several 100k users. No issue at all.

> Making TEXT a part of the primary key is not the best idea. Does it have performance implications by default or is it just a precaution for avoiding accidentally expensive primary keys? > Just running the command mentioned in the changelog works well even for several 100k users. No issue at all. Thank you ☺️

> Does it have performance implications by default or is it just a precaution for avoiding accidentally expensive primary keys? Perofrmance implication by deafult. But i guess that will only come up with millions of rows anyway. Either way, i don't see this column length changing in the future.

I also spotted a small issue in the changelog: https://github.com/supertokens/supertokens-core/pull/514

ah thanks! merged 🙂