Better Auth: Framework-Agnostic Authentication Solution for TypeScript Apps
Syncfusion provides third-party UI components for React, Vue, Angular, JavaScript, Blazor, .NET MAUI, ASP.NET MVC, Core, WinForms, WPF, UWP and Xamarin.
TL;DR: Designing authentication that survives framework changes is hard. This article explains how Better Auth enables framework-agnostic authentication for TypeScript apps, covering its architecture, performance, trade-offs, and real-world use cases, including Next.js, Remix, and SvelteKit. You’ll see how a self-hosted auth stack with small bundles, fast session validation, and full data ownership can improve maintainability, scalability, and long-term flexibility without framework lock-in.
Modern web teams rarely sit still. A product might start with Next.js, later experiment with Remix, or grow an Express API alongside the frontend. Frameworks change, architectures evolve, but authentication tends to stick around long after the original decisions were made.
That’s where things usually get painful.
Authentication is often tightly coupled to a framework or outsourced to a managed service, which can become expensive and inflexible over time. Migrating frameworks means rewriting the auth logic. Scaling users means scaling costs. And gaining deeper control usually means more work than teams expect.
Better Auth approaches this problem differently.
Instead of treating authentication as a framework feature, it treats it as infrastructure you own : portable, TypeScript-first, and designed to survive framework changes.
In this article, we’ll look at how Better Auth works, where it fits well, and when it might not be the right choice.
Why framework-agnostic authentication matters
At the start of a project, most authentication solutions feel fine. They’re easy to set up, tightly integrated, and well-documented. The trade-offs only surface later.
Teams usually run into trouble when:
A frontend framework migration is needed
Multiple frameworks coexist in the same system
User growth triggers unexpected pricing models
Deeper control over sessions or data becomes necessary
In these situations, authentication becomes an anchor. The tighter it’s bound to one framework or vendor, the harder it is to move.
Better Auth is built for teams that expect change and want authentication to be portable by design , not something that must be rewritten every time the stack evolves.
How Better Auth works (Core concepts and architecture)
Better Auth is a TypeScript‑first authentication library designed around HTTP and databases, not frameworks.
At its core, it connects three layers:
Database layer: Stores users, sessions, credentials, and verification data in your own database.
Authentication core: Handles password hashing, session creation, validation, and security logic.
Framework adapters: Translate framework requests into auth operations without embedding framework logic into the auth layer.
The result : One authentication configuration that works across Next.js, Remix, SvelteKit, and Express. Frameworks pass requests through; Better Auth handles the rest.
What you gain by owning the auth layer
This architectural shift comes with some clear benefits.
Framework portability: Authentication is no longer tied to a single framework’s lifecycle. You can migrate or experiment without rewriting the auth from scratch.
Type safety end-to-end: Because schemas generate TypeScript types, your authentication logic stays consistent across the stack.
Full data ownership: Users, sessions, and credentials live in your database, not inside a third-party system. That gives you control over behavior, retention, and performance.
Predictable costs: There’s no per-user pricing. Costs scale with infrastructure, not with user count.
For teams that have felt boxed in by framework-specific auth or rising managed-service costs, this alone can be compelling.
Performance and trade‑offs
Better Auth is designed to be lightweight and fast, but it’s also transparent about what you’re taking on.
In typical setups:
The auth bundle is relatively small, often in the
~10-15 kB gzippedrange, depending on configurationSession validation can often complete in tens of milliseconds with proper indexing and low-latency database access Sessions are database-backed, keeping memory usage predictable
That said, owning authentication also means owning its responsibilities.
You’re responsible for:
Database migrations and cleanup
Monitoring session tables
Email delivery and rate limiting
Security hardening beyond the defaults
Better Auth favors control over convenience. For teams comfortable with backend infrastructure, that’s a reasonable trade. For teams looking for zero-maintenance auth, it may not be.
Note: Performance metrics are estimates and vary based on infrastructure, database location, connection quality, and load. Always benchmark in your specific environment.
What a minimal Better Auth setup looks like
To understand how Better Auth works in practice, it helps to look at a minimal setup. Instead of walking through commands or file-by-file instructions, let’s break this into the core layers and how they interact.
At a high level, the setup has three parts:
A data layer that stores users and sessions
An authentication layer that handles login and session logic
A thin UI layer that interacts with the auth system
The key difference is that these layers remain independent of the framework.
The stack (and why it stays minimal)
This example uses Next.js, SQLite, and Drizzle ORM, not because Better Auth requires them, but because they keep the setup lightweight and easy to reason about.
Better Auth itself is framework-agnostic. The framework simply acts as a transport layer for requests, while authentication logic lives independently.
The data layer: owning your auth data
Let’s start with the foundation: the data layer. This is where Better Auth changes the usual approach.
Instead of storing authentication data inside a managed service or hiding it behind a framework, everything lives directly in your database.
In practice, this typically translates into a small set of core tables:
user: stores profile information
session: tracks active sessions and expiration
account: manages credentials or provider accounts
verification: handles temporary tokens like email verification
The exact structure can vary, but the important shift is ownership. Authentication data is no longer abstracted away. It becomes part of your application’s data model.
This also means it evolves with your product. Schema changes, indexing, and performance tuning become part of your responsibility, not something delegated to a third-party system.
The authentication layer: where everything connects
Once the data layer is in place, the next piece is the authentication layer, where everything comes together.
This is where Better Auth becomes the center of the system. Instead of spreading authentication logic across routes, controllers, or framework-specific APIs, everything is defined in one place.
The database connects through an adapter, and authentication methods such as email and password are enabled declaratively. From that point on, the same logic handles every request, regardless of where it originates.
That consistency is what makes the approach powerful. Whether a request comes from Next.js, Remix, or an Express API, it flows through the same authentication layer. This separation is what enables true framework portability.
The UI layer: surprisingly thin
On the frontend, authentication is handled as a thin client, with most logic delegated to the backend.
A typical sign-up experience becomes a thin layer that collects user input and forwards it to the authentication system. Most of the complexity, such as validation, password hashing, and session management, happens behind the scenes.
This keeps the UI simple and allows the same backend logic to serve multiple frontends without duplication.
Route protection without framework lock-in
Protecting routes comes down to validating whether a session exists.
In frameworks like Next.js, this is often implemented using middleware. However, the important detail is that the session validation logic itself is not tied to the framework; it’s handled by Better Auth.
This means the same approach works regardless of the framework you use, avoiding one of the most common sources of lock-in.
If you’d like to explore the full implementation, including schema definitions, API routes, and UI components, you can refer to the complete working example on GitHub. The repository complements this article by showing how these concepts translate into a working application.
Common pitfalls to avoid
Missing database indexes on session tokens, which can significantly slow protected routes.
Localhost cookie issues during development, consistent hostnames matter.
No rate limiting by default, login endpoints should always be protected against brute‑force attempts.
These are infrastructure responsibilities that come with self-hosted authentication.
Better Auth vs other authentication options
Choose Better Auth if you:
Expect framework changes over time
Want predictable infrastructure‑based costs
Need full control over authentication data and behavior
Work primarily in TypeScript with backend experience
Choose framework-specific auth if you:
Are committed to a single framework long‑term
Prefer ecosystem maturity over portability
Want minimal setup and maintenance
Choose managed auth services if you:
Need production‑ready auth immediately
Prefer vendor‑managed compliance and SLAs
Accept per‑user pricing and vendor lock‑in
Solution comparison
Solution | Infrastructure Cost | Bundle Size | Framework Lock | Pricing Model |
Better Auth | Self-hosted (typical small-scale setups may start around | ~12 KB | None | Fixed infrastructure |
NextAuth | Self-hosted (typical small-scale setups may start around | ~45 KB | Next.js only | Fixed infrastructure |
Auth0 | ~80 KB | None | Per-user + features | |
Clerk | ~65 KB | None | Per-user + features |
Self-hosted costs assume managed PostgreSQL (\(20/mo) and hosting (\)10-40/mo). Managed service pricing varies by user count and features; check official pricing pages for current rates.
Frequently Asked Questions
Q1. Can I migrate from NextAuth or Auth0 without losing user data?
Yes, but it requires manual data migration to export users from your existing system, map to Better Auth’s schema, and have users reset passwords on first login.
Q2. Is Better Auth stable enough for production use?
Better Auth is open-source and has started to see adoption in production use cases, but lacks the enterprise SLAs that managed services provide. Review the GitHub repository for activity, issue resolution, and community size. Always run security audits on your authentication implementation before production deployment.
Q3. Does Better Auth work with OAuth providers like Google and GitHub?
Yes, Better Auth supports major OAuth providers through plugins. Install the social provider plugin, configure client credentials, and Better Auth handles the OAuth flow.
Conclusion
Thank you for reading! Better Auth delivers true framework portability without sacrificing security or performance. You get small bundle sizes, typically smaller than many framework-specific auth libraries like NextAuth, along with fast session validation that can complete in around 10 to 12 milliseconds in optimized setups, and the ability to switch frameworks without rewriting auth code.
The trade-off is clear: you gain framework independence and predictable infrastructure costs, but manage your own infrastructure. Database migrations, session cleanup, and email delivery become your responsibility.
This makes Better Auth ideal for teams that value control over convenience, especially at scale, where per-user pricing models can become costly. If you have backend experience and want to avoid framework lock-in, Better Auth fits.
The example above illustrates how the pieces come together in a minimal setup. In practice, the full implementation can be explored through the GitHub repository.
From there, add OAuth providers, 2FA, or passkeys through Better Auth’s plugin system as requirements evolve.
Authentication complexity hasn’t disappeared; it’s just shifted to infrastructure you control. Curious how this approach fits into your own projects? Share your thoughts in the comments below.
