Los posts de comparación de bases de datos serverless en 2026 generalmente están escritos por personas que han usado un proveedor y leyeron las páginas de marketing de los otros cuatro. Esta es la versión después de ejecutar cargas de trabajo en producción en Supabase, Neon, y un puñado de proyectos de clientes en PlanetScale, Turso, y Convex durante los últimos 18 meses. Cinco proveedores, datos reales en producción, sin enlaces de afiliados.Supabase, Neon, and a handful of client builds across PlanetScale, Turso, and Convex over the last 18 months. Five providers, real production data, no affiliate links.
Lo clave: Supabase es la opción integrada por defecto, Neon es la elección del purista de Postgres, PlanetScale gana en branching de MySQL, Turso gana en lecturas en edge, y Convex gana en reactividad nativa de TypeScript.Supabase is the bundled default, Neon is the Postgres purist pick, PlanetScale wins MySQL branching, Turso wins edge reads, and Convex wins TypeScript-first reactivity.
Ejecuto Supabase como la principal en este sitio, en HostList (el directorio de 91,000 páginas), en el WordPress Stack Advisor, y en la mayoría del trabajo con clientes en el último año. El cluster HIPAA en este sitio está construido en gran medida con Supabase -- la configuración de cuidado de la salud de $700/mes con Vercel-más-Supabase es la arquitectura que adopto por defecto para cualquier proyecto de cuidado de la salud que no necesite específicamente un proveedor diferente. El análisis honesto que sigue cubre dónde Supabase gana, dónde las alternativas genuinamente la superan, y dónde la elección es más cerrada de lo que el marketing sugiere.WordPress Stack Advisor, and on most client work in the last year. The HIPAA cluster on this site is largely Supabase-built -- the $700/month Vercel-plus-Supabase healthcare setup is the architecture I default to for any healthcare project that does not specifically need a different vendor. The honest take below covers where Supabase wins, where the alternatives genuinely beat it, and where the choice is closer than the marketing implies.
Los cinco proveedores en 60 segundos
- Supabase -- Postgres-as-a-service con Auth, Storage, Realtime, Edge Functions y pgvector integrados. Pro $25/mes, Team $599/mes, complemento HIPAA $350/mes en Team o Enterprise. La más incluida de las cinco.
- Neon -- Postgres-as-a-service, ramificación-primero (cada deploy de preview obtiene una rama de base de datos), escala serverless hasta cero. Nivel gratuito generoso, Launch $19/mes, Scale $69/mes.
- PlanetScale -- MySQL-as-a-service, basado en vitess para sharding, flujos de ramificación. Eliminó el nivel gratuito en 2024. Scaler $39/mes, Pro $79+/mes, Scaler Pro para producción en niveles más altos.
- Turso -- SQLite distribuido (libSQL), replicación edge-first, nivel gratuito con 9GB y 1B de lecturas de filas, Scaler $29/mes. La más rápida en edge para cargas de trabajo con lectura intensiva.
- Convex -- base de datos reactiva TypeScript-first con funciones integradas, consultas en tiempo real, sin SQL. Gratuito 1GB, Pro $25/puesto, niveles Team y Enterprise. La más opinada de las cinco.
Dónde cada proveedor realmente gana
Supabase: app + contenido + auth en un Postgres
Supabase es la opción correcta cuando tu aplicación y contenido comparten una base de datos y quieres autenticación, almacenamiento y tiempo real incluidos sin integrar cinco proveedores separados. El Postgres debajo es Postgres real -- pgvector para características de IA, SQL completo, RLS para seguridad multi-tenant. El complemento HIPAA a $350/mes en Team es el camino más limpio para cuidado de la salud con un producto con forma de Postgres. La desventaja es que el plan Pro ($25/mes) es genuinamente limitado para producción -- Team a $599/mes es donde viven las cargas de trabajo serias, y el salto de precio es real.
- Gana en: apps full-stack, healthcare con HIPAA, proyectos que necesitan pgvector para IA, equipos que quieren un vendedor para DB+auth+almacenamiento.
- Falla en: escrituras pesadas multi-región (las réplicas de lectura ayudan pero el single-master de Postgres es el límite), briefs de solo base de datos donde las características incluidas son ruido.
Neon: branching de Postgres para preview deploys
La característica estrella de Neon es la ramificación -- cada deploy de preview de Vercel obtiene su propia rama Postgres efímera con los datos completos, sin fixtures. Para equipos que lanzan múltiples PRs por semana con cambios que tocan la base de datos, esta única característica paga la migración. La escala serverless hasta cero es genuinamente útil para ambientes de staging y aplicaciones de bajo tráfico. La desventaja: Neon es un servicio solo de base de datos, así que traes tu propia autenticación, almacenamiento, tiempo real. Opción correcta cuando específicamente quieres Postgres sin el paquete.Vercel preview deploy gets its own ephemeral Postgres branch with the full data, no fixtures. For teams that ship multiple PRs per week with database-touching changes, this single feature pays for the migration. The serverless scale-to-zero is genuinely useful for staging environments and low-traffic apps. The downside: Neon is a database-only service, so you bring your own auth, storage, real-time. Right call when you specifically want Postgres without the bundle.
- Gana en: flujo de trabajo de desarrollo con ramificación, proyectos solo de Postgres, equipos que ya usan Auth0/Clerk/Cognito para autenticación.
- Se queda corto en: falta de autenticación/almacenamiento integrado significa que coses servicios, sin HIPAA en el tier Launch (solo Scale y superior).
PlanetScale: MySQL a escala con ramificación
PlanetScale fue el pionero del database branching pero eliminó su tier gratuito en 2024, lo que afectó materialmente la adopción por desarrolladores indie. La decisión es correcta ahora para equipos que ya están en MySQL a escala y quieren branching más sharding de Vitess sin tener que ejecutarlo ellos mismos. Excelente DX, plataforma madura. Mala decisión para proyectos que de otra forma elegirían Postgres -- cambiar de Postgres a MySQL solo por la característica de branching raramente vale la pena ahora que Neon ofrece el mismo flujo de trabajo en Postgres.
- Gana en: cargas de trabajo MySQL existentes a escala, equipos que necesitan sharding con Vitess.
- Se queda corto en: desarrolladores indie/tier gratuito (sin tier gratuito desde 2024), equipos interesados en Postgres que se beneficiarían más de Neon.
Turso: SQLite orientado al edge para cargas de trabajo con mucha lectura
Turso (libSQL, el fork de SQLite) replica tu base de datos al edge globalmente y sirve lecturas desde la región donde el usuario se conecta. Para aplicaciones con lectura intensiva -- sitios de contenido con contenido impulsado por base de datos, catálogos de ecommerce, directorios -- la ganancia de latencia es dramática. El tier gratuito de 9GB y 1 billón de lecturas de filas es genuinamente generoso. El problema: SQLite tiene semántica de transacciones diferente a Postgres, las aplicaciones con escritura intensiva no son el ajuste óptimo, y el ecosistema de ORMs y herramientas es más pequeño que para Postgres o MySQL.
- Gana en: apps distribuidas al edge con mucha lectura, sitios de contenido con contenido impulsado por base de datos a escala, tier gratuito generoso.
- Se queda corto en: cargas de trabajo con mucha escritura, transacciones complejas de múltiples tablas, proyectos ya invertidos en herramientas del ecosistema de Postgres.
Convex: base de datos reactiva con TypeScript como protagonista
Convex es la más opinionada de las cinco -- definiciones de esquema en TypeScript, funciones de servidor en TypeScript, consultas en tiempo real por defecto, sin SQL. Para equipos que quieren permanecer en TypeScript de extremo a extremo y valoran la experiencia del desarrollador sobre flexibilidad, Convex es genuinamente productiva. El compromiso es el lock-in: no hay escape hatch de SQL, el modelo de datos es específico de Convex, y migrar fuera de Convex es una reconstrucción completa en lugar de una exportación de base de datos.
- Destaca en: equipos que priorizan TypeScript, apps con mucha actividad en tiempo real, prototipos a producción donde la velocidad del DX importa.
- Se queda corta en: cualquiera que necesite flexibilidad de SQL, proyectos con requisitos fuertes de portabilidad de datos, consultas analíticas complejas.
Árbol de decisión -- elige según el brief
App full-stack con contenido + auth + tiempo real + funciones de IA
Supabase. Las funciones agrupadas (Auth, Storage, Realtime, pgvector) realmente ahorran gastos generales de gestión de proveedores. La configuración de Supabase compatible con HIPAA + Vercel cubre la versión de grado producción incluyendo la historia del BAA.The HIPAA-compliant Supabase + Vercel setup covers the production-grade version including the BAA story.
Proyecto solo Postgres con necesidades serias de flujo de trabajo de desarrollo
Neon. El branching por cada deploy de vista previa es la función diferenciadora. Combina con Auth0, Clerk, o Supabase Auth (sí, puedes usar Supabase Auth sin usar su base de datos) para la capa de autenticación.
Carga de trabajo MySQL a escala con requisitos de sharding
PlanetScale. La combinación única de sharding Vitess más branching. Si empiezas de cero, evalúa Neon primero; si ya estás en MySQL a escala y quieres la plataforma sin ejecutarla tú mismo, PlanetScale justifica el precio.
App de contenido distribuido con mucha lectura
Turso. SQLite en el edge con 1B de lecturas gratis es realmente una forma diferente. Indicado para directorios de contenido, catálogos de e-commerce, sitios SEO programático donde la latencia de lectura domina la experiencia del usuario.
Equipo solo TypeScript, producto en fase prototipo, time-first en tiempo real
Convex. La velocidad DX para equipos TypeScript es real. Acepta el trade-off de lock-in; revísalo si el producto va a escalar hacia algo que requiera SQL o portabilidad de datos.
Economía de costos -- TCO anual para una carga de trabajo típica
Anclado a una hipotética app SaaS: 10K usuarios activos, 5GB de base de datos, 100K solicitudes API por día, equipo de 5 ingenieros, deploys semanales.
- Supabase Team: $599/mes base. Más add-on HIPAA $350/mes si aplica. ~$11,400/año (o $7,200 sin HIPAA).
- Neon Scale: $69/mes + uso basado en compute y storage, típicamente $40-100/mes adicional. ~$1,500-2,500/año.
- PlanetScale Scaler Pro: $79/mes + uso. ~$1,500-2,500/año para carga similar.
- Turso Scaler: $29/mes más uso. ~$500-800/año.
- Convex Pro: $25/asiento × 5 + uso = ~$2,000-4,000/año.
Supabase se ve cara en papel a esta escala, pero la comparación es injusta -- Neon, PlanetScale, Turso y Convex son servicios de base de datos únicamente. Agregar auth equivalente (Clerk Pro $25/mes + $0.02/MAU), almacenamiento (Cloudflare R2 ~$15/mes), tiempo real (Pusher $49/mes o auto-hospedado), y pgvector (administrado vía embeddings de OpenAI + una DB vectorial) típicamente suma $200-500/mes adicionales. Una vez que agrupas las integraciones, Supabase Team frecuentemente se vuelve competitivo en costo.
FAQ
¿Es Supabase mejor que Neon?
Para apps full-stack con requisitos de auth, almacenamiento y tiempo real, sí -- Supabase agrupa características que Neon no tiene. Para proyectos solo Postgres con necesidades serias de flujo de trabajo de desarrollo, el branching de Neon es el diferenciador. Los dos están optimizados para briefs diferentes; la elección raramente es sobre cuál es 'mejor' en términos absolutos.
¿Por qué PlanetScale eliminó el nivel gratuito?
Sostenibilidad -- ejecutar Postgres o MySQL por cliente sin costo es genuinamente caro a escala, y PlanetScale eligió enfocarse en clientes que generan ingresos sobre la audiencia indie/de aprendizaje. La decisión hirió su developer-mindshare significativamente; Neon y Turso capturaron la mayoría de la atención indie desde entonces. PlanetScale sigue siendo una opción fuerte para equipos establecidos en MySQL pero ya no es el default para nuevos proyectos.
¿Es Turso una verdadera alternativa a Postgres?
No, Turso usa libSQL (una bifurcación de SQLite), que tiene semántica de transacciones diferente, sin características de relación multi-tabla completa, y un ecosistema más pequeño. Para cargas de trabajo pesadas en lectura en el edge es genuinamente más rápido que Postgres, pero para bases de datos de aplicación de propósito general Postgres sigue siendo la opción más flexible.
¿Puedo usar Convex para algo más que aplicaciones en TypeScript?
En teoría sí -- Convex tiene SDKs para Python y otros lenguajes -- pero la historia de productividad está construida alrededor de desarrollo TypeScript-primero. Los equipos usando Convex desde stacks no-TypeScript tienden a sentir fricción que la arquitectura no está diseñada para absorber. Para equipos no-TypeScript, Supabase o Neon usualmente es el mejor ajuste.
¿Cuál base de datos serverless tiene la mejor historia HIPAA?
Supabase, con el add-on HIPAA a $350/mes en el plan Team ($599/mes). La capa de plataforma combinada con Vercel Pro BAA a $350/mes te deja en $700/mes para un stack Next.js + Supabase HIPAA defendible. Configuración completa detallada aquí. Neon y PlanetScale ofrecen HIPAA en tiers más altos; Turso y Convex no tienen historias HIPAA publicadas a mediados de 2026.Full setup detailed here. Neon and PlanetScale offer HIPAA on higher tiers; Turso and Convex do not have published HIPAA stories as of mid-2026.
Lecturas relacionadas
Supabase compatible con HIPAA + Vercel: la configuración de $700/mes -- setup de producción para apps de salud usando Supabase como capa de datos. -- production setup for healthcare apps using Supabase as the data layer.
Headless CMS Hub -- cuando la elección de capa CMS intersecta con la elección de base de datos (Supabase como contenido vs CMS separado). -- when the CMS layer choice intersects with the database choice (Supabase as content vs separate CMS).
Cómo construí un directorio de 25,000 páginas en Next.js -- el caso de estudio de producción a escala, con Supabase como la columna vertebral de datos. -- the production case study at scale, with Supabase as the data backbone.
WordPress Stack Advisor -- la herramienta en sí se ejecuta en Supabase + Vercel; referencia de producción para el patrón Supabase + Next.js. -- the tool itself runs on Supabase + Vercel; production reference for the Supabase + Next.js pattern.
La elección de base de datos rara vez es el cuello de botella. El cuello de botella es si el equipo puede entregar con cualquier base de datos que elijas. Elige por primitive-fit, no por checklist de características.
Agenda una llamada de base de datos de 30 minutos -- describe la forma de la app, la experiencia en stack del equipo, la proyección de escala. Termina con una decisión Supabase-vs-Neon-vs-Turso que se ajuste al brief. -- describe the app shape, the team's stack expertise, the scale projection. Walk away with a Supabase-vs-Neon-vs-Turso decision that fits the brief.