From Supabase to Clerk to Better Auth

Original Article ↗ Hacker News Discussion ↗

Better Auth vs. Clerk (and Supabase)

  • Pro‑Better Auth comments highlight:
    • Auth data lives in your own database, not a vendor’s.
    • One CLI command to set up tables; works with any DB provider.
    • Many built‑in features (OAuth providers, plugins, JWT, offline/mobile support, iframe auth) and open source; optional managed hosting.
    • Perceived as more “hackable” and transparent than SaaS products; easier to debug.
    • Free for self‑hosted use; attractive vs. per‑user SaaS pricing.
  • Critiques of Clerk include:
    • Heavy, slow JS bundles and complex isomorphic TS code; painful upgrades and dependency conflicts (e.g., with Stripe).
    • Missing enterprise features (e.g., audit logs, configuration versioning).
    • Operational issues: outages, token refresh failures, no robust offline auth on mobile.
    • Confusing or limited RBAC model; org‑scoped roles only.
  • Some defend Clerk, noting strong adoption (e.g., large startups), good for rapid prototyping, and that online complaints may be skewed.

Framework Auth & “Roll Your Own” Debate

  • Many argue mature frameworks (Django, Rails, Laravel, ASP.NET Core, Phoenix/Elixir) ship solid auth, user, and role systems; no need for separate SaaS.
  • Others point out that “auth = users table + hashed password” is outdated; modern apps often need SSO, SAML, SCIM, OAuth/OIDC, MFA, passkeys, social login, multi‑tenant orgs, etc.
  • Some describe building custom auth as feasible but time‑consuming; bugs around rate limiting, 2FA, lockouts, and SSO are common.
  • Distinction is drawn between:
    • Not rolling your own crypto or security protocols vs.
    • Sensibly using libraries and running auth yourself vs.
    • Delegating everything to a hosted SaaS.

When to Outsource Auth

  • Pro‑SaaS arguments:
    • Auth is a “productivity tarpit”; non‑differentiating but critical.
    • Third‑party vendors handle security, certifications, and complex enterprise SSO demands.
    • Reduces in‑house ops burden (vs. running Keycloak, etc.).
  • Anti‑SaaS arguments:
    • Extra critical dependency reduces overall availability; reliability is roughly the product of all critical components.
    • Vendor lock‑in, pricing risk, opaque behavior, and limited customization.
    • Hard migrations (password hashing differences, SSO/SCIM/passkey re‑setup, parallel cookie handling).
    • Some see piling Supabase + Clerk as a red flag for security maturity.

Alternatives & Ecosystem Notes

  • Mentioned options: Auth0, WorkOS, FusionAuth, Keycloak, Ory, Authelia, Authentik, Lucia (now mostly documentation), and framework‑specific libraries (e.g., Rails “authentication‑zero”).
  • Consensus trend in the thread: move away from hosted auth SaaS toward libraries or self‑hosted systems that keep user data local, unless enterprise SSO needs and team constraints strongly justify a service.