Better Auth vs Clerk vs Supabase Auth para un SaaS mexicano (2026): la decisión honesta
Para un SaaS mexicano nuevo en 2026, elige Better Auth si quieres una librería TS-native que guarda tus usuarios en tu propio Postgres con multi-tenancy de primera (pero parchea antes el CVE-2025-61928). Elige Supabase Auth si ya estás en Supabase y quieres que RLS haga la mitad de tu autorización. Usa Clerk solo cuando el mejor DX justifique el costo y la residencia de datos solo en EE. UU. sea aceptable.
La decisión de auth 2026, desde un escritorio de SaaS mexicano
Llevo años conectando auth en SaaS que cobran de verdad, y a 2026 la pregunta “¿qué uso para autenticación?” dejó de ser un empate de cinco opciones. Para un SaaS nuevo, hoy es una carrera de dos caballos: Better Auth o Supabase Auth. Clerk sigue ahí, pero como la opción de “pago por velocidad”, no como la opción por defecto.
Te enmarco a los tres rápido, porque la diferencia es de modelo, no de features:
- Better Auth: una librería de auth TypeScript-native. Tus usuarios viven en tu propio Postgres, con multi-tenancy de primera. Tú eres dueño de la superficie operativa.
- Supabase Auth: la mejor opción si ya estás en Supabase y quieres que Row Level Security (RLS) haga la mitad de tu autorización dentro de la base.
- Clerk: hosted, el mejor DX, pero más caro y solo con datos en EE. UU. a 2026.
Ahora, la parte que casi nadie escribe: desde un escritorio mexicano, los ejes que de verdad mueven la decisión no son “qué tan bonito es el SDK”. Son cuatro: residencia de datos (dónde vive la información de tus usuarios), costo a escala, multi-tenancy y quién responde ante un parche o una brecha. Esos cuatro deciden, no la página de marketing.
Opinión, y la etiqueto como opinión: no hay un ganador universal. Es un trade entre propiedad operativa y outsourcing. Si alguien te dice que una herramienta gana siempre, te está vendiendo, no comparando. Para la base de esta comparativa me apoyo en el análisis de makerkit.
Better Auth / Supabase
- Better Auth: tu propio Postgres, residencia donde tú elijas
- Multi-tenancy de primera (Better Auth)
- Supabase: RLS hace media autorización en la base
- Costo bajo a escala (~$187/mo Supabase a 100k MAU)
Clerk
- Hosted, el mejor DX
- Datos solo en EE. UU. a 2026
- ~$1,825/mo a 100k MAU
- Delegas parches y respuesta a brechas
Better Auth: tus usuarios en tu propio Postgres
Better Auth no es un servicio hosted: es una librería TypeScript-native. Eso cambia todo. Tus usuarios no viven en la base de datos de un tercero; viven en tu Postgres, en la región que tú elijas. Para un SaaS mexicano que tarde o temprano va a tener que justificar dónde guarda PII, eso es una ventaja real de residencia de datos: la residencia es simplemente la región de tu Postgres.
Lo segundo que importa para B2B es que trae multi-tenancy de primera. Si cada cliente es un tenant, no estás parchando aislamiento a mano: la librería lo contempla. Aquí va una forma ilustrativa de cómo se ve esa intención en código:
// Ilustrativo: estructura multi-tenant con auth en tu propio Postgres
// El usuario autenticado trae su organizationId (tenant)
async function loadTenantData(session: Session) {
const tenantId = session.activeOrganizationId; // tenant del usuario
// toda query se filtra por tenant — el aislamiento es tuyo
return db.query.invoices.findMany({
where: eq(invoices.organizationId, tenantId),
});
}Ahora la parte honesta. Better Auth trae rate limiting, pero eso no es un WAF. Sigues necesitando una capa edge consciente de IP enfrente; el rate limiting de la librería no te cubre un ataque distribuido. Y al ser self-hosted, tú eres dueño de la superficie operativa: tú aplicas los parches y tú respondes ante una brecha. Lo digo como costo, no solo como beneficio. La libertad de “own your users” viene con la factura de “own your incidents”.
El CVE de Better Auth que no puedes saltarte
Si vas a usar Better Auth, esto no es opcional leerlo. En 2025 salió el CVE-2025-61928: creación de API keys sin autenticación a través del plugin de api-key. La lógica de autorización estaba mal hecha y permitía a un atacante pasar un userId en el body y saltarse la auth por completo. La severidad fue crítica (CVSS v4 9.3) porque habilitaba account takeover. Se parchó en la versión 1.3.26.
Más allá del bug puntual, levantó preguntas justas sobre la madurez del proceso de security review en una librería self-hosted donde tú eres quien responde ante la brecha. No es para descartar la herramienta; es para entender exactamente qué firmas cuando te autoalojas.
El takeaway operativo es concreto:
- Fija la versión a
>=1.3.26(no uses ninguna anterior) y mantente por encima de ese piso. - Rota cualquier API key creada durante la ventana de exposición.
- Vigila los advisories de forma activa, no reactiva.
Esto es precisamente el tipo de trabajo que te toca cuando te autoalojas. Detalles del advisory: busca “Better Auth CVE-2025-61928”.
Supabase Auth: deja que RLS haga la mitad de tu autorización
Supabase Auth gana claro en un caso: cuando ya estás en Supabase. La auth está conectada al mismo Postgres, así que no estás cosiendo dos sistemas. Un solo lugar para usuarios y datos, una sola región que verificar.
La joya aquí es Row Level Security. RLS puede hacer aproximadamente la mitad de tu autorización en la capa de base de datos, lo que significa menos bugs de autorización viviendo en tu código de aplicación. Una política se ve así de simple:
-- Ilustrativo: RLS para que cada quien vea solo sus filas
-- Se asume que org_id viaja en el JWT como texto
alter table invoices enable row level security;
create policy "tenant_isolation" on invoices
for select
using ( organization_id::text = auth.jwt() ->> 'org_id' );Esa política vive en la base. Aunque tu código de app tenga un descuido, Postgres no te entrega filas de otro tenant. Esa es la ventaja real.
Costo: alrededor de $187/mo a 100,000 MAU (a 2026, verifica el actual). La residencia de datos depende de la región de tu proyecto Supabase, así que confirma que soporta la localidad que necesitas antes de comprometerte. Y átalo a entitlements: la auth es la puerta; RLS más tu capa de entitlements es lo que realmente desbloquea features por plan o por tenant. Si quieres profundizar en esa capa, lo desarrollo en entitlements y límites de uso en SaaS.
Clerk: el mejor DX, datos solo en EE. UU., una cuenta más alta
Clerk es hosted y tiene el mejor DX de los tres: delegas toda la superficie operativa —parches, respuesta a brechas, infra— y arrancas en una tarde. Eso es real y vale.
Las tres objeciones, todas reales para un SaaS mexicano:
- Más caro: alrededor de $1,825/mo a 100,000 MAU (a 2026, verifica el actual) contra los ~$187/mo de Supabase. No es un redondeo; es un orden de magnitud.
- Pricing inestable: ha cambiado dos veces en tres años. Si estás modelando costos a varios años, eso es un riesgo de planeación.
- Solo EE. UU. a 2026: la información de tus usuarios vive en una base de datos en EE. UU. Es una preocupación real de residencia de datos y GDPR, y vale la pena sopesarla también para residencia de datos en LATAM.
Opinión, etiquetada: Clerk es excelente para llegar a PMF rápido. El patrón que veo con frecuencia es migrar alrededor de los 50k MAU, cuando la factura empieza a llamar la atención de ingeniería. No es un error usarlo; es saber cuándo te va a empezar a costar.
Auth es la puerta, los entitlements son lo que abre
Esto lo veo mal montado todo el tiempo, así que lo separo explícito. Sea cual sea tu elección, la auth solo prueba QUIÉN es el usuario. No decide QUÉ puede hacer. Eso son los entitlements —plan, rol, límites de tenant— y son una capa aparte que tú posees sin importar el proveedor de auth.
Con Supabase Auth, RLS puede forzar parte de esto en la base. Con Better Auth o Clerk, conectas los entitlements en código de app. Pero el principio práctico es el mismo: mantén la capa de entitlements agnóstica del proveedor. Si mañana migras de Clerk a Better Auth, no quieres reescribir todo tu modelo de autorización solo porque cambiaste de quién valida el login.
Eso también aplica al cobro: tus usuarios autenticados son los que pagan, y esa conexión la detallo en cómo integrar Stripe en tu SaaS. Y para mantener el estado de auth y de cobro sincronizado de forma confiable, el patrón correcto importa: lo comparo en webhooks vs polling vs API.
Elige el tuyo: una decisión de 30 segundos
No te voy a dejar con “depende”. Aquí está el camino corto:
- ¿Ya estás en Supabase y quieres RLS?Supabase Auth (~$187/mo a 100k MAU a 2026). Deja que RLS haga media autorización.
- ¿Quieres tu propio Postgres, multi-tenant y TS-native?Better Auth. Primero parchea el CVE-2025-61928 a >=1.3.26 y rota llaves expuestas.
- ¿Necesitas el DX más rápido, puedes pagar y datos en EE. UU. está bien?Clerk (~$1,825/mo a 100k MAU a 2026). Velocidad a cambio de costo y residencia US-only.
Para la mayoría de SaaS mexicanos y de LATAM me inclino por Better Auth o Supabase Auth (opinión, etiquetada). Clerk compra velocidad a cambio de costo y datos solo en EE. UU. Límite honesto: esto es un trade entre propiedad operativa y outsourcing, no una respuesta única.
Preguntas frecuentes
¿Better Auth es seguro después del CVE? Se parchó en 1.3.26. La lección no es “es inseguro”, es que autoalojar significa que tú eres dueño del parcheo y de la respuesta a brechas. Fija una versión reciente y vigila los advisories.
¿Puedo usar Clerk desde México? Técnicamente sí, pero la información de tus usuarios queda en una base de datos en EE. UU. a 2026. Sopésalo para residencia de datos y GDPR antes de comprometerte.
¿Supabase Auth reemplaza mi capa de autorización? No. RLS hace una parte; tú sigues siendo dueño de los entitlements.
¿Qué es lo más barato a 100k MAU? Better Auth (librería gratis, solo pagas el hosting de tu DB), luego Supabase ~$187/mo, luego Clerk ~$1,825/mo (a 2026, verifica el actual).
¿Y el tema fiscal o de cumplimiento? No soy contador. Dónde debes almacenar PII por ley fiscal o de privacidad necesita un asesor real. Yo soy ingeniero y te hablo de arquitectura, no de obligaciones legales.
El cierre honesto
No hay ganador universal. Elige por residencia de datos, costo a escala, multi-tenancy y quién responde ante una brecha. Esos cuatro ejes deciden, no el marketing.
Para un SaaS mexicano o de LATAM nuevo en 2026, me inclino por Better Auth o Supabase Auth (opinión, etiquetada). Los precios son a 2026: verifica el actual antes de comprometerte. Y si quieres más guías de ingeniería para armar tu SaaS, las junto en integraciones.