Same library, same tables, two jobs. Neon Auth for a prototype or a simple app: sign-in in minutes, nothing to host or patch, users branching with the database. Better Auth run yourself for a client app that has to grow: every plugin, your own keys and claims, and no lock-in.
When to pick which
Pick Neon Auth when
- A prototype, an MVP or a simple app: email and password, Google or GitHub sign-in, magic links, and nothing to host or patch.
- You want users to branch with the database, so every preview branch has its own test users.
- Neon's sign-in options are all the app will ever need.
Pick Better Auth, run yourself when
- A client app meant to grow: MFA, passkeys, enterprise SSO, SCIM or teams are on the roadmap.
- Tokens must work with AWS: RS256 or ES256 for API Gateway JWT authorizers and IAM, and your own claims in them.
- You need your own plugins, hooks or sign-in providers (Microsoft, Apple, LinkedIn).
- The Neon project uses IP Allow or Private Networking, where Neon Auth can't be enabled.
Both, when
- Not in one app: pick one user store. But they're the same library and the same core tables, so starting on Neon Auth and moving to your own Better Auth later is a migration, not a rewrite.
- Plan that move before launch: there's no supported export, and users should expect to sign in again.
Questions that change the answer
Will a client's staff need MFA, passkeys or their corporate login within a year? Neon Auth has none of them today.
Will anything on AWS verify the tokens (API Gateway, IAM)? Neon Auth signs with EdDSA only, which neither accepts.
Who patches the auth? Neon does on Neon Auth; you do, every week, on your own.
The short version
| Neon Auth (managed Better Auth) | Better Auth, run yourself | |
|---|---|---|
| What it is | Better Auth hosted by Neon, next to your database | The open-source library, inside your backend |
| Status | Generally available since September 2026; the SDK is still beta | Version 1.7, MIT |
| Where users live | Your Neon database, neon_auth schema |
Your Neon database, tables you choose |
| Users branch with the database | Yes, per branch | Only if you put the tables on the branch |
| Sign-in methods | Email and password, Google, GitHub, Vercel, email codes, magic links | All of those, plus about 36 social providers, passkeys, MFA |
| MFA, passkeys | No (MFA "coming soon") | Yes |
| Enterprise SSO (SAML, OIDC), SCIM | No | Yes |
| Organisations | Partial, beta | Yes, with teams and custom roles |
| Your own plugins and hooks | No: webhooks on 7 events only | Yes |
| Tokens | EdDSA only, 15 minutes, no custom claims | RS256, PS256, ES256 or EdDSA, your own claims |
| Emails | Neon's shared sender (codes only), your SMTP, or webhooks to Resend | Your code, any provider |
| Hosting and patching | Neon | You: a Lambda in the client's region, updated weekly |
| Price | Included in every Neon plan: 60,000 monthly users free, 1M on paid plans | $0 per user |
| Sydney | Yes | Wherever you run it |
| Leaving | No supported export to self-hosted | Nothing to leave |
Why I run it myself for client apps
The sign-in guide explains why Better Auth is my first pick for serious apps on Postgres: one user store, more features than Cognito, no per-user fee. Neon Auth is the same library, so the question is only who runs it.
For a client app, the answer is me. The things Neon doesn't expose are exactly what a growing business app asks for in its second year: MFA, passkeys, a client's corporate login, organisations with real roles. And the tokens matter on AWS. Neon Auth signs with EdDSA only, and API Gateway's JWT authorizers accept RSA only, while IAM accepts RSA or ECDSA. Run yourself, Better Auth issues RS256 tokens that Workers, API Gateway and IAM all verify, with the claims you choose.
When Neon Auth is the right call
For a prototype, an internal tool or a simple product, Neon Auth removes the parts I'd otherwise build: there's no auth endpoint to host, no Lambda, nothing to patch. It's included in the Neon plan, and its best trick is branching. Each preview branch gets its own users and settings, so a test sign-up never touches production.
Two things to know before you rely on it:
- One signing key for every branch. Tokens from a preview branch carry a valid signature on production; only the issuer differs. Check
isswherever you verify a token. - Emails. The default sender is shared, rate-limited, branded and sends codes only, not verification links. Point it at your own SMTP, or handle the
send.otpandsend.magic_linkwebhooks with Resend.
Moving from one to the other
The core tables have the same names as Better Auth's own (user, account, session, verification), so moving from Neon Auth to your own Better Auth looks like a SQL job. But Neon documents no export and warns against promising that sessions survive, so check the columns, the password hashes and the plugin tables on a branch first, and expect users to sign in again. If the app is likely to need SSO or MFA, start on your own Better Auth and skip the move.
Patching
Neon patches its service and upgrades the Better Auth version behind it without any change on your side, but publishes no patch commitment or advisory feed. Better Auth published many high and critical advisories in 2026. Run it yourself and you patch it: pin exact versions, let Renovate or Dependabot open the upgrades, and have a weekly job check the advisories, as the sign-in guide describes.
Sources, checked on 25 October 2026: Neon Auth overview, Neon Auth plugins, Neon Auth roadmap, branching authentication, production checklist, Neon pricing, Better Auth JWT plugin, API Gateway JWT authorizers, IAM OIDC providers, Better Auth security advisories.