Better Auth vs Clerk: dlaczego wybraliśmy Better Auth

Better Auth vs Clerk sprowadza się do jednego pytania: gdzie żyją Państwa użytkownicy i sesje? Clerk trzyma je w swojej hostowanej usłudze. Better Auth zapisuje je w Państwa własnej bazie danych, jako zwykłe tabele obok reszty aplikacji.

W każdej nowej aplikacji przeszliśmy z NextAuth na Better Auth i nigdy nie wybraliśmy Clerka. Najpierw uczciwe zastrzeżenie: nie używaliśmy Clerka na produkcji. To więc nie jest benchmark. To wyjaśnienie, dlaczego go nie wybraliśmy, z konfiguracjami, których naprawdę używamy.

Jaka jest różnica między Better Auth a Clerkiem?

Better Auth to biblioteka. Opisuje się jako "a framework-agnostic, universal authentication and authorization framework for TypeScript" (dokumentacja Better Auth, stan na 24.10.2026). Ma licencję MIT. Clerk to hostowana usługa z gotowymi komponentami logowania i panelem użytkowników.

O wyborze zdecydowały u nas wiersz drugi i trzeci. Nasi klienci są właścicielami kodu, danych i infrastruktury od pierwszego dnia. Tabela użytkowników na cudzych serwerach, rozliczana za użytkownika, do tego nie pasuje.

Dlaczego przeszliśmy z NextAuth na Better Auth?

Nasze starsze aplikacje klientów działają na NextAuth v4 z adapterem Prisma. Nadal działają i ich nie ruszamy. Działającego uwierzytelniania nie przepisujemy na potrzeby artykułu.

Przy nowych aplikacjach decyzja stała się prostsza we wrześniu 2025 roku. Auth.js, projekt wcześniej nazywany NextAuth.js, przeszedł pod zespół Better Auth. Ich ogłoszenie mówi to wprost:

Luka, którą wymieniają, to bezstanowe sesje bez bazy danych. My i tak chcemy mieć bazę danych, więc nas to nigdy nie dotyczyło.

Jak wygląda Better Auth w prawdziwej aplikacji?

To pakiet uwierzytelniania z naszego szablonu startowego, lekko skrócony. TanStack Start na Cloudflare Workers, Drizzle na D1:

import { betterAuth } from 'better-auth'
import { drizzleAdapter } from 'better-auth/adapters/drizzle'
import { tanstackStartCookies } from 'better-auth/tanstack-start'
import { checkout, polar, portal } from '@polar-sh/better-auth'

export function createAuth() {
  const db = createDb()
  const plugins = [tanstackStartCookies()]

  // Płatności tylko wtedy, gdy aplikacja ma token płatności.
  if (env.POLAR_ACCESS_TOKEN) {
    plugins.push(polar({ client: polarClient, createCustomerOnSignUp: true, use: [checkout({ /* produkty */ }), portal()] }))
  }

  return betterAuth({
    database: drizzleAdapter(db, { provider: 'sqlite', schema }),
    trustedOrigins: [env.CORS_ORIGIN],
    emailAndPassword: { enabled: true },
    socialProviders: { /* Google i GitHub, tylko gdy ich klucze są ustawione */ },
    secret: env.BETTER_AUTH_SECRET,
    baseURL: env.BETTER_AUTH_URL,
    plugins,
  })
}

Schemat też jest nasz. Użytkownicy i sesje to tabele Drizzle jak każde inne:

const user = sqliteTable('user', {
  id: text('id').primaryKey(),
  name: text('name').notNull(),
  email: text('email').notNull().unique(),
  emailVerified: integer('email_verified', { mode: 'boolean' }).default(false).notNull(),
})

const session = sqliteTable('session', {
  id: text('id').primaryKey(),
  token: text('token').notNull().unique(),
  expiresAt: integer('expires_at', { mode: 'timestamp_ms' }).notNull(),
  userId: text('user_id').notNull().references(() => user.id, { onDelete: 'cascade' }),
})

To jest różnica w praktyce. Rekord utworzony przez użytkownika to klucz obcy do user.id w tej samej bazie danych. Raport „kto co zrobił” to jeden JOIN w SQL, a nie wywołanie zewnętrznego API plus zadanie synchronizacji.

Jak uwierzytelnianie staje się częścią Państwa własnego kodu?

Nasza wewnętrzna aplikacja cockpit pokazuje, jak daleko to sięga. Zarejestrować się może tylko krótka lista osób, wszystkie przez GitHub. Żadne ustawienie u dostawcy uwierzytelniania tego nie robi. To kilka linii w hooku bazy danych:

return betterAuth({
  database: drizzleAdapter(db, { provider: 'sqlite', schema }),
  emailAndPassword: { enabled: false },
  databaseHooks: {
    user: {
      create: {
        before: async (user) => {
          if (allowedEmails.length > 0 && !allowedEmails.includes(user.email.toLowerCase())) return false
        },
      },
    },
  },
  socialProviders: { github: { clientId, clientSecret, scope: ['repo', 'read:user', 'user:email'] } },
})

Co dzieje się przy rejestracji:

Lista dozwolonych adresów to zmienna środowiskowa. Jej zmiana to wdrożenie, sprawdzane jak każda inna zmiana. Przy hostowanej usłudze ta sama reguła żyłaby w panelu albo w webhooku poza repozytorium.

Których pluginów Better Auth używamy na produkcji?

Każdy plugin to kod w repozytorium, więc listę łatwo sprawdzić:

• Nasz szablon startowy: tanstackStartCookies i plugin płatności Polar (checkout i portal klienta, klient tworzony przy rejestracji). Polar jest dodawany tylko wtedy, gdy istnieje token.
• Aplikacja webowa klienta: Better Auth w Payload CMS, z admin, organization, twoFactor, emailOTP, magicLink, multiSession i pluginem passkey.
• Marketplace internetowy klienta: osobna usługa uwierzytelniania na MongoDB z magicLink i oidcProvider. Pozostałe aplikacje marketplace'u logują się przez nią jak przez każdego dostawcę OpenID Connect.

Trzy bazy danych, trzy konfiguracje, jedna biblioteka. To cenimy najbardziej: ta sama biblioteka pasuje do SQLite na edge'u, Postgresa za CMS-em i MongoDB w osobnej usłudze.

Kiedy Clerk jest lepszym wyborem?

Clerk ma sens, gdy chcą Państwo mieć logowanie gotowe w tym tygodniu, a nikt w zespole nie powinien utrzymywać kodu uwierzytelniania. Gotowe komponenty oszczędzają ekrany. Clerk wysyła e-maile i łata usługę. Do prototypu darmowy plan jest hojny: 50 000 aktywnych użytkowników miesięcznie na aplikację, Pro za 25 USD miesięcznie i 0,02 USD za użytkownika od 50 001 do 100 000 (cennik Clerka, stan na 24.10.2026).

Uzależnienie jest mniejsze, niż się wydaje. Clerk pozwala administratorom wyeksportować użytkowników, łącznie z zahashowanymi hasłami, jako CSV (dokumentacja Clerka, stan na 24.10.2026). Dane nie są zakładnikiem. Pracy wymaga wszystko, co jest do nich podpięte: interfejs logowania, sprawdzanie sesji na serwerze i dane użytkowników skopiowane do Państwa własnych tabel.

Jeszcze jeden fakt do rozważenia. Better Auth dołączył do Vercela 7 lipca 2026 roku. Ich wpis mówi: "Vercel shares our commitment to keeping auth open source, framework and platform agnostic." (blog Better Auth). Licencja MIT pozostaje taka, jaka jest. Odnotowujemy to tak, jak każdą zmianę właściciela zależności, na której polegamy.

Co Państwo biorą na siebie, gdy uwierzytelnianie jest Państwa?

Własne uwierzytelnianie nie jest wolne od pracy. Praca przechodzi na Państwa zespół. Zanim wybiorą Państwo Better Auth, proszę przejść tę listę:

Ostatni punkt to najtańsze ubezpieczenie. Nasz szablon startowy uruchamia testy Playwright dokładnie w tym celu: formularz logowania się wyświetla, rejestracja działa, a panel bez sesji przekierowuje do logowania.

Jak na tym uwierzytelnianiu udostępniamy dane aplikacji agentom AI, opisujemy w Jak zbudować serwer MCP i kiedy tego nie robić.

Potrzebują Państwo uwierzytelniania, które zostaje w Państwa bazie danych?

Budujemy aplikacje webowe, w których użytkownicy, sesje i uprawnienia żyją we własnej bazie danych klienta, w ramach tworzenia aplikacji webowych na zamówienie. Kod, dane i infrastruktura należą do klienta od pierwszego dnia. Większość naszego kodu pisze AI. Senior sprawdza każdą zmianę i odpowiada za to, co działa na produkcji. Od 2023 roku dostarczyliśmy ponad 15 projektów produkcyjnych.

Odezwiemy się w ciągu dwóch dni roboczych z kilkoma pytaniami o Państwa pracę. Potem ustalimy, co zrobimy najpierw.

Jeśli wolą Państwo najpierw porozmawiać, proszę zarezerwować 15-minutową rozmowę wstępną.

Gdzie dziś żyją Państwa użytkownicy i czy dałoby się ich wyciągnąć jednym JOIN-em w SQL?

Najczęstsze pytania

Jaka jest różnica między Better Auth a Clerkiem?

Better Auth to otwartoźródłowa biblioteka TypeScript, która zapisuje użytkowników i sesje w Państwa własnej bazie danych. Clerk to hostowana usługa, która przechowuje je za Państwa i daje gotowy interfejs logowania. Wybór jest między kontrolą i brakiem rachunku za użytkownika a mniejszą ilością własnego kodu do utrzymania.

Czy Better Auth jest darmowy?

Tak. Better Auth ma licencję MIT. Płacą Państwo za to, na czym działa: bazę danych, hosting i usługę e-mail, która wysyła linki weryfikacyjne i magic linki.

Ile kosztuje Clerk?

Według stanu na 24.10.2026 plan Hobby w Clerku jest darmowy z limitem 50 000 aktywnych użytkowników miesięcznie na aplikację, Pro kosztuje 25 USD miesięcznie (20 USD przy płatności rocznej), a użytkownicy od 50 001 do 100 000 kosztują po 0,02 USD miesięcznie. Aktualne liczby są na clerk.com/pricing.

Czy przejść z NextAuth na Better Auth?

W nowych projektach tak: Auth.js utrzymuje teraz zespół Better Auth i to on zaleca Better Auth do nowych prac. Działającej aplikacji na NextAuth nie migrujemy dla samej migracji. Zmieniamy, gdy aplikacja potrzebuje funkcji, której NextAuth nie ma.

Czy można później odejść od Clerka?

Tak. Clerk pozwala administratorom wyeksportować użytkowników, łącznie z zahashowanymi hasłami, jako CSV z panelu. Pracy wymaga reszta: interfejs logowania, sprawdzanie sesji i dane użytkowników zsynchronizowane do Państwa własnych tabel.