Migrate off of user.userId
Migrate away from tracking user.userId in the component user table
tl;dr
The Better Auth component has it's own user table. Your app may have it's own
user table as well. These tables are related via the userId field in the
Better Auth user table. The component facilitates this relationship as a special
case, but is going to stop doing that in a future release.
Why?
Originally the component schema couldn't be configured. This is now possible through Local Install. Moving forward, keeping two user tables should be a project decision that is explicitly configured rather than a built in pattern that often brings confusion.
Do I need to do anything?
If your app has it's own user table and the userId field is populated in any
of your betterAuth user table records, you will need to follow the migration
guide below. Otherwise, you can ignore this guide.
Migration options
Keep current behavior
If avoiding a data migration is the most important thing for you, this is the way to go.
If you want to maintain the current approach, you can configure Better Auth to do that. If you already use Local Install, want to continue keep using two user tables, and are fine with the app user id being tracked in the component user table, this will be the simplest approach.
Track component user id in app table
If avoiding using Local Install is the most important thing for you, this is the way to go.
This is the generally recommended approach for apps that will continue using two
app tables. It doesn't require Local Install. This approach involves migrating
from tracking the app user id in the component to tracking the component user id
in the app user table via an authId field.
A data migration is required to backfill the authId field.