Upgrading to 0.11

Upgrade the peers togetherCopy Anchor Link

better-auth@^1.7, plus @better-auth/api-key / @better-auth/passkey at the same major if you use them.

Generate the migration, then backfill issuer (1.7.0–1.7.2 only)Copy Anchor Link

Better Auth 1.7.0 keyed provider identities on (issuer, accountId) instead of providerId, so the accounts collection gained a required issuer field plus a unique index. payload migrate:create emits an ADD COLUMN … NOT NULL that fails on a populated table. Split it into add-nullable, backfill, enforce:

ALTER TABLE accounts ADD COLUMN issuer varchar;

-- Email/password rows
UPDATE accounts SET issuer = 'local:credential' WHERE provider_id = 'credential';
-- OAuth rows: the issuer each provider DECLARES (see below)
UPDATE accounts SET issuer = 'https://accounts.google.com' WHERE provider_id = 'google';
UPDATE accounts SET issuer = 'https://www.facebook.com'    WHERE provider_id = 'facebook';
-- Only providers that declare no issuer of their own get the synthetic form
UPDATE accounts SET issuer = 'local:oauth:' || provider_id WHERE issuer IS NULL;

ALTER TABLE accounts ALTER COLUMN issuer SET NOT NULL;
-- then the unique index exactly as Payload generated it

Before enforcing, confirm the backfill produced no duplicates. This must return zero rows, or the unique index fails:

SELECT issuer, account_id, COUNT(*)
FROM accounts GROUP BY issuer, account_id HAVING COUNT(*) > 1;

Table and column names assume the defaults on Postgres (pluralized slug accounts, snake_case columns). Adjust for usePlural: false, a custom account model name, or MongoDB.

Read a provider's issuer instead of guessing it:

node -e "import('better-auth/social-providers').then(m => console.log(m.google({clientId:'x',clientSecret:'y'}).accountIssuer))"

Microsoft Entra ID needs a row-by-row backfill, and its account_id moves too. Its issuer is per tenant (https://login.microsoftonline.com/<tid>/v2.0), so there is no constant to write, and 1.7 keys the subject on the oid claim where 1.6 stored sub. Both values are in the id_token already on the row: decode the claims segment (base64url) and take iss and oid. Decode only; there is no signature to check, because this reads a claim from your own database rather than a token presented by a caller.

Facebook's account_id does not move. Facebook rows need only the issuer update. For any other provider you use, compare its 1.7 accountSubject with how 1.6 derived the id; where they disagree, account_id needs migrating alongside issuer.

Apply the migration and verifyCopy Anchor Link

Apply it and verify sign-in for each provider you support. No application-code changes are required for the common setup; the adapter, generated collections and admin UI absorb the rest of 1.7.