Better Auth: Framework-Agnostic Authentication Solution for TypeScript Apps

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:

1. Database layer: Stores users, sessions, credentials, and verification data in your own database.
2. Authentication core: Handles password hashing, session creation, validation, and security logic.
3. 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 gzipped range, depending on configuration
• Session 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.

Read the full blog post on the Syncfusion Website