Neon vs PlanetScale (2026): Benchmark de Arquitectura Serverless Postgres vs MySQL / Vitess

1. Desacoplamiento de Cómputo y Almacenamiento: Pageservers en Rust vs Topologías Sharded en Vitess

Para comprender la brecha funcional entre Neon y PlanetScale, es imprescindible analizar cómo cada sistema fragmenta la arquitectura tradicional de un motor relacional monolítico. Mientras que la primera generación cloud (como Amazon Aurora) desacopló el almacenamiento sustituyendo el sistema de ficheros por volúmenes SSD distribuidos compartidos, Neon y PlanetScale adoptan modelos cloud-native radicalmente distintos.

La Arquitectura de Desacoplamiento Profundo de Neon: Pageserver, Safekeeper y Flujos LSN

Neon reconstruyó la capa de almacenamiento de PostgreSQL desde cero utilizando Rust. En una instalación estándar de Postgres, la planificación de consultas, el buffer pool, el log transaccional (WAL) y los ficheros físicos en disco (páginas de 8KB) residen en el mismo host. Neon divide esta estructura en tres componentes desacoplados:

• Nodos de Cómputo (Compute Nodes): Son instancias efímeras de PostgreSQL que se ejecutan dentro de microVMs (o contenedores) ligeros sin almacenamiento persistente local. El binario de Postgres únicamente ha sido parcheado en la interfaz de gestión de almacenamiento (smgr). Si una consulta requiere una página de 8KB ausente en el buffer RAM local, la microVM no realiza una llamada de lectura al sistema de archivos local, sino que solicita la página por red a un Pageserver.
• Nodos Safekeeper: Un conjunto de nodos que ejecutan un algoritmo de consenso distribuido basado en Paxos. Cuando un cliente ejecuta un COMMIT, el nodo de cómputo transmite el flujo WAL a los Safekeepers. Tan pronto como la mayoría confirma la persistencia de estos bytes hasta un número de secuencia de log (LSN) concreto, la transacción se da por confirmada con total durabilidad.
• Pageservers (Almacenamiento Distribuido en Rust): Ingestionan continuamente los registros WAL desde los Safekeepers y reconstruyen el estado de las páginas en cualquier punto temporal. Además, compactan periódicamente las versiones de páginas y las descargan en almacenamiento de objetos (Amazon S3 o GCS) en archivos inmutables en capas, reduciendo exponencialmente el coste del almacenamiento en reposo.

La Arquitectura Vitess de PlanetScale: VTGate, VTTablet y Sharding Horizontal Transparente

PlanetScale no altera el motor de almacenamiento subyacente de MySQL (InnoDB) ni divide los ficheros .ibd. En su lugar, sustenta su infraestructura en Vitess, el proyecto de código abierto concebido originalmente por los ingenieros de YouTube para escalar MySQL a miles de millones de usuarios concurrentes.

El desacoplamiento de PlanetScale opera mediante orquestación y enrutamiento horizontal:

• Enrutadores VTGate: Proxies sin estado de alta disponibilidad. Cuando la aplicación envía una consulta SQL estándar o mediante la API HTTP de PlanetScale, VTGate intercepta la petición, consulta la definición declarativa de particionamiento (VSchema), determina a qué shard específico debe dirigirse la consulta y coordina la ejecución en paralelo si requiere acceder a múltiples particiones.
• Agentes VTTablet: Procesos demonio que se ejecutan junto a cada instancia de mysqld. VTTablet actúa como un guardián inteligente: protege a MySQL frente a tormentas de consultas, limita la concurrencia máxima para evitar la degradación de memoria del sistema y gestiona la replicación transaccional.
• Sharding Horizontal mediante VReplication: Cuando una tabla supera los límites físicos de escritura o almacenamiento de un servidor único, PlanetScale permite dividir el keyspace en 2, 4, 8 o más shards utilizando claves hash o por rango. Esta reorganización transaccional se efectúa en caliente mediante VReplication sin detener las operaciones de lectura y escritura de la aplicación.

Conclusión Arquitectónica: Neon rediseña los fundamentos del almacenamiento de Postgres para que el cómputo sea completamente descartable y las copias de datos sean instantáneas a coste marginal cero. PlanetScale mantiene los motores MySQL convencionales intactos, pero añade una sofisticada capa de enrutamiento y sharding distribuido diseñada para procesar millones de escrituras por segundo a escala masiva.

2. Mecánicas de Branching en Bases de Datos: LSN Copy-on-Write vs Deploy Requests

Ambas plataformas sitúan el "branching" (ramificación) en el núcleo de su propuesta de valor para desarrolladores. No obstante, el significado técnico de una "rama" difiere diametralmente entre ambas plataformas.

Neon: Branching Instantáneo Copy-on-Write al Nivel de Página y LSN

En Neon, el branching es una propiedad nativa de su Pageserver en Rust. Dado que cada modificación de datos queda registrada como una capa delta asociada a un LSN específico, generar una nueva rama es conceptualmente idéntico a crear una rama en Git:

• Creación en Milisegundos: Crear una rama requiere entre 500 y 1.200 milisegundos, sin importar si la base de datos principal almacena 50 Megabytes o 15 Terabytes de datos.
• Cero Duplicación Inicial de Almacenamiento: La rama hija apunta al LSN actual (o a un LSN pasado para depuración o auditoría temporal). El Pageserver comparte las capas base ya existentes.
• Aislamiento Total Copy-on-Write: A medida que la rama ejecuta operaciones de inserción, actualización o borrado, únicamente las nuevas páginas modificadas de 8KB se escriben en la línea temporal de esa rama. La base de datos de producción permanece 100% aislada e intacta.
• Datos Reales en Entornos de Pull Request: Gracias a que cada rama contiene la totalidad del volumen de datos de producción, las pruebas de integración en entornos efímeros (como Vercel Previews o CI en GitHub Actions) detectan problemas de rendimiento de consultas sobre volúmenes reales de información antes de llegar a producción.

# 1. Crear una rama aislada copy-on-write desde main al instante
neon branches create \
  --project-id ecommerce-production \
  --name pr-preview-842 \
  --parent main

# 2. Extraer la cadena de conexión para el contenedor de pruebas
DATABASE_URL=$(neon connection-string --branch pr-preview-842)

# 3. Aplicar migraciones con Prisma / Drizzle y correr tests de integración
pnpm prisma migrate deploy
pnpm test:e2e

# 4. Eliminar la rama automáticamente al cerrar o fusionar el PR
neon branches delete --branch pr-preview-842

PlanetScale: Branching de Esquema Seguro y Deploy Requests

PlanetScale popularizó el branching en bases de datos relacionales, pero su enfoque técnico se centra en la seguridad en la evolución de esquemas DDL más que en clonar volúmenes masivos de datos para cada desarrollador:

• Ramas de Desarrollo Centradas en Esquema: Una rama de desarrollo genera una instancia aislada de MySQL que contiene la definición de tablas y tipos, pero sin clonar inicialmente los registros de producción. Esto previene fugas de información confidencial (PII) hacia entornos de desarrollo locales.
• Flujo de Deploy Requests: Una vez alterado el esquema en la rama de desarrollo, el ingeniero genera un Deploy Request mediante la consola o la CLI de PlanetScale.
• Linter Automático de Esquemas: PlanetScale comprueba que el DDL no introduzca antipatrones que pongan en peligro la réplica o el rendimiento del clúster (como claves foráneas que bloqueen tablas particionadas o consultas sin índices adecuados).

# 1. Crear rama de desarrollo para experimentar con el esquema
pscale branch create backend-prod add-invoicing-indexes

# 2. Conectarse de forma segura mediante túnel local y aplicar DDL
pscale shell backend-prod add-invoicing-indexes
mysql> ALTER TABLE invoices ADD INDEX idx_invoices_customer_date (customer_id, issued_at);

# 3. Abrir el Deploy Request para validar la fusión en producción
pscale deploy-request create backend-prod add-invoicing-indexes

# 4. Desplegar el cambio en producción sin bloqueos mediante gh-ost
pscale deploy-request deploy backend-prod 15

3. Scale-to-Zero vs Cómputo Warm: Análisis de Latencia de Arranque en Frío

La elección entre apagado automático a cero (scale-to-zero) y cómputo siempre encendido (warm compute) define el equilibrio entre optimización de costes y latencia en el percentil 99.

El Funcionamiento de Scale-to-Zero en Neon

Neon permite que los endpoints de cómputo se apaguen automáticamente cuando no detectan conexiones activas durante una ventana de inactividad configurable (típicamente 5 minutos en desarrollo o hasta 24 horas en producción).

Cuando un endpoint se suspende:

1. El proceso Postgres escribe las páginas sucias hacia los Pageservers y la microVM se desasigna por completo.
2. La facturación por hora de cómputo baja a 0,00 $/segundo mientras el endpoint permanezca inactivo. Únicamente se factura el almacenamiento base.
3. Un proxy de conexión permanece a la escucha. Al recibir una nueva petición SQL o un handshake TCP, el proxy retiene los paquetes, ordena al orquestador levantar una nueva microVM, enlaza con la línea temporal del Pageserver y completa la respuesta.

En nuestras pruebas de laboratorio sobre 1.000 ciclos de arranque en frío en AWS us-east-1:

• Latencia Mediana de Despertar (p50): 540 milisegundos.
• Percentil 95 (p95): 980 milisegundos.
• Percentil 99 (p99): 1.320 milisegundos (incluyendo los fallos iniciales de página hacia el Pageserver).

La Filosofía de PlanetScale: Cómputo Warm y Cero Latencia de Arranque

En 2024, PlanetScale eliminó su tier gratuito con scale-to-zero para enfocarse exclusivamente en planes de producción (Scaler y Scaler Pro) con cómputo siempre activo.

El argumento técnico de PlanetScale sostiene que, en bases de datos relacionales de producción para aplicaciones web críticas, el scale-to-zero introduce picos de latencia inaceptables para APIs de cara al usuario, degradando los Core Web Vitals y arriesgando caídas en cascada por time-outs en microservicios.

Bajo PlanetScale Scaler Pro:

• Cero Arranques en Frío: Las instancias de cómputo (desde PS-10 hasta PS-400) operan calientes las 24 horas del día.
• Buffer Pools de InnoDB Precalentados: Los datos calientes e índices residen permanentemente en la memoria RAM, ofreciendo latencias de consulta inferiores a 1,5 ms desde la primera llamada.
• Pausa de Ramas de Desarrollo: Aunque producción nunca duerme, las ramas secundarias pueden pausarse cuando los desarrolladores no las utilicen.

4. Connection Pooling a Gran Escala: Driver WebSocket de Neon vs VTGate en Vitess

Las bases de datos relacionales tradicionales no fueron concebidas para la naturaleza efímera del cómputo serverless en el edge (Vercel Edge Middleware, Cloudflare Workers, Supabase Functions o AWS Lambda). Una avalancha repentina de tráfico puede generar 15.000 ejecuciones concurrentes de funciones lambdas, cada una intentando establecer su propia conexión TCP hacia el motor de datos.

En PostgreSQL estándar, cada conexión consume unos 10MB de memoria del servidor e inicializa un proceso del sistema operativo independiente. Intentar abrir 5.000 conexiones concurrentes contra Postgres colapsa el servidor con errores de memoria insostenibles.

La Solución de Neon: pgBouncer Integrado y Driver Serverless sobre WebSockets

Neon neutraliza el problema de saturación mediante una doble estrategia:

1. Capa de pgBouncer Integrada: Neon expone de forma directa un endpoint de agrupación de conexiones en el puerto 5432 con pooling por transacción. Añadiendo -pooler al nombre de host, hasta 10.000 conexiones simultáneas pueden multiplexarse sobre un conjunto acotado de procesos worker reales de Postgres.
2. Driver Neon Serverless (@neondatabase/serverless): Para entornos edge donde los sockets TCP persistentes están restringidos o presentan sobrecoste de negociación TLS, Neon diseñó un driver que transporta consultas SQL mediante WebSockets seguros (WSS) o llamadas HTTP fetch sin estado.

import { neon } from '@neondatabase/serverless';

// Cliente HTTP sin estado: Cero riesgo de saturación de conexiones en Edge
const sql = neon(process.env.DATABASE_URL!);

export async function GET(request: Request) {
  // Se ejecuta mediante HTTP/1.1 o HTTP/2 sin mantener sockets TCP abiertos
  const usuarios = await sql`
    SELECT id, email, nombre_completo, creado_el 
    FROM usuarios 
    WHERE estado = 'activo' 
    LIMIT 25;
  `;
  return Response.json(usuarios);
}

La Solución de PlanetScale: La Fortaleza de Concurrencia de VTGate y Fetch API

El enrutador VTGate de Vitess fue construido específicamente para resistir las oleadas masivas de tráfico de YouTube y GitHub:

• Multiplexación en VTGate: VTGate puede absorber cientos de miles de conexiones cliente simultáneas. Mantiene pools de conexiones persistentes de alto rendimiento hacia los demonios VTTablet, reutilizando sockets y descartando consultas tóxicas antes de que agoten los hilos de MySQL.
• Driver PlanetScale Database (@planetscale/database): De manera análoga a Neon, PlanetScale ofrece un driver HTTP ligero basado en fetch() que permite ejecutar consultas relacionales desde Cloudflare Workers o lambdas sin penalización por handshake de conexión.

import { connect } from '@planetscale/database';

const config = {
  host: process.env.DATABASE_HOST,
  username: process.env.DATABASE_USERNAME,
  password: process.env.DATABASE_PASSWORD,
};

// Conexión directa mediante la API Fetch sobre HTTP POST
const conn = connect(config);

export default {
  async fetch(request: Request): Promise {
    const res = await conn.execute(
      'SELECT id, sku, precio_centavos FROM inventario WHERE en_stock = ? LIMIT 50',
      [true]
    );
    return new Response(JSON.stringify(res.rows));
  }
};

5. Migraciones de Esquema DDL sin Bloqueos: gh-ost en Vitess vs DDL Transaccional en Postgres

Las migraciones de esquema constituyen una de las operaciones de mayor riesgo en la ingeniería de datos. Ejecutar una sentencia ALTER TABLE sobre una tabla con 100 millones de filas puede adquirir bloqueos exclusivos de metadatos, encolando todas las consultas de la aplicación y derivando en caídas catastróficas del servicio.

La Joya de la Corona de PlanetScale: DDL Online sin Bloqueos mediante gh-ost

El mayor factor diferencial de PlanetScale reside en su sistema de migraciones desatendidas y seguras impulsadas por gh-ost y VReplication:

1. Creación de la Tabla Fantasma (Ghost Table): PlanetScale crea una tabla réplica temporal con el nuevo esquema aplicado.
2. Copia sin Triggers mediante Inspección del Binlog: A diferencia de utilidades antiguas que instalaban triggers síncronos sobre la tabla activa, PlanetScale lee de forma asíncrona el binary log de MySQL. Copia los registros existentes en pequeños lotes regulados mientras sincroniza los cambios en tiempo real.
3. Throttling Dinámico: Si la réplica de lectura experimenta retraso o la CPU del nodo primario supera umbrales de seguridad, el proceso de migración frena automáticamente su ritmo para proteger el tráfico de los usuarios.
4. Intercambio Atómico de Tablas: Una vez igualada la tabla fantasma, PlanetScale ejecuta un renombrado atómico. El tiempo total de bloqueo es inferior a 20 milisegundos.
5. Reversión Instantánea (Revert): Si el nuevo esquema provoca un error imprevisto en la aplicación, PlanetScale permite revertir el cambio de inmediato sin pérdida de registros.

Neon: DDL Transaccional, Pruebas en Ramas y pg_roll

PostgreSQL cuenta históricamente con una ventaja crucial frente a MySQL tradicional: el soporte para DDL transaccional. En Postgres, operaciones como CREATE TABLE, ALTER TABLE y DROP INDEX pueden envolverse en un bloque BEGIN ... COMMIT. Si cualquier sentencia falla, la transacción revierte por completo sin dejar esquemas inconsistentes.

No obstante, PostgreSQL puede bloquear tablas si se añaden índices sin la cláusula CONCURRENTLY o si se modifican tipos de datos que fuerzan la reescritura de la tabla.

Neon mitiga este riesgo mediante dos estrategias avanzadas:

• Ensayos en Ramas con Datos Reales: Dado que crear una rama en Neon toma menos de un segundo y clona el 100% de los datos de producción a coste cero, los pipelines de CI/CD pueden ejecutar la migración completa sobre una copia fiel antes de tocar producción, detectando bloqueos y regresiones de forma anticipada.
• Despliegues Progresivos con pg_roll: En entornos que requieren cero tiempo de inactividad estricto, los equipos combinan Neon con librerías como pg_roll, que orquesta esquemas multiversión mediante vistas actualizables para despliegues blue/green.

6. Modelado FinOps Matemático y TCO en Tres Escenarios Reales

El impacto económico de ambas plataformas varía drásticamente según la naturaleza de la carga de trabajo, el número de desarrolladores activos y el ratio de operaciones de lectura versus escritura.

Métricas de Tarificación de Neon (2026)

• Cómputo Activo: ~0,16 $ por Compute Unit (CU) / hora (1 CU = 1 vCPU + 4 GB RAM). Con scale-to-zero, el coste baja a 0,00 $/hora en inactividad.
• Almacenamiento Activo: 1,50 $ por GB/mes en los Pageservers.
• Escritura de Datos Sintéticos: 0,096 $ por GB escrito en WAL.
• Transferencia de Red (Egress): 0,09 $ por GB transferido a internet.

Métricas de Tarificación de PlanetScale (2026)

• Plan Scaler Base: 39,00 $/mes (incluye 10GB de almacenamiento, 100M lecturas de filas/mes y 10M escrituras/mes).
• Scaler Pro (Cómputo Dedicado): Base de 39 $/mes + tamaño de instancia PS (PS-10 a PS-400), almacenamiento a 2,50 $ por GB/mes, 1,00 $ por cada 1.000 millones de lecturas de filas y 1,50 $ por cada millón de escrituras.
• Enterprise / Clúster Sharded: Planes anuales dedicados con soporte de claves de particionamiento personalizadas y VPC peering.

7. Rendimiento de Laboratorio: Latencias de Lectura/Escritura y Saturación QPS

En nuestros bancos de prueba de laboratorio, ejecutamos pruebas de saturación de consultas punto (Point Reads), inserciones transaccionales masivas y consultas analíticas complejas para comparar el comportamiento real de ambos motores.

8. Seguridad Empresarial, Cumplimiento Normativo y Aislamiento de Red

Para responsables de seguridad de la información (CISOs) y directores de cumplimiento que evalúan la transición desde entornos tradicionales hacia infraestructura relacional gestionada, el aislamiento y la custodia de datos son requisitos inexcusables.

Certificaciones de Seguridad y Residencia de Datos

Tanto Neon como PlanetScale cuentan con las principales acreditaciones de seguridad del mercado:

• SOC 2 Tipo II: Informes de auditoría independientes sobre controles de seguridad, disponibilidad y confidencialidad en ambas compañías.
• ISO 27001: Sistemas de gestión de la seguridad de la información certificados internacionalmente.
• Cumplimiento HIPAA y Acuerdos BAA: Ambas plataformas suscriben Business Associate Agreements (BAAs) para aplicaciones del sector salud que gestionan datos de salud protegidos (PHI).
• RGPD y Soberanía Geográfica: Permiten fijar la residencia del cómputo y del almacenamiento en regiones cloud de la Unión Europea (como Fráncfort o Dublín) y en Estados Unidos para satisfacer normativas locales de privacidad.

Aislamiento de Red: AWS PrivateLink y VPC Peering

• PlanetScale Managed y PrivateLink: PlanetScale ofrece soporte nativo para AWS PrivateLink y VPC Peering. El tráfico entre clústeres Kubernetes o ECS del cliente y los proxies de Vitess viaja a través del backbone privado de AWS sin exponerse a internet pública. Además, la modalidad PlanetScale Managed permite desplegar la totalidad del clúster Vitess dentro de la propia cuenta de AWS del cliente.
• Neon Private Networking: Neon soporta listas blancas de IPs en todos los planes y ofrece integración con AWS PrivateLink en sus planes Enterprise, garantizando canales de comunicación privados hacia las VPCs corporativas.

Retención de Datos Cero y Privacidad en Cargas de IA

Con la proliferación de aplicaciones GenAI y arquitecturas RAG apoyadas en pgvector, Neon ofrece garantías contractuales de Retención de Datos Cero (Zero Data Retention): los datos de los clientes, logs de consultas relacionales y vectores semánticos jamás se utilizan para entrenar modelos de inteligencia artificial propios o de terceros.

9. Matriz Comparativa Técnica Frente a Frente

La siguiente tabla resume exhaustivamente los parámetros técnicos, capacidades arquitectónicas y valoraciones globales de Neon y PlanetScale en 2026.

10. Análisis Detallado de Ventajas y Limitaciones

11. Veredicto Final y Árbol de Decisión de Arquitectura

La elección entre Neon y PlanetScale en 2026 no responde a qué motor es genéricamente superior, sino a las necesidades de escala, flujo de despliegue y modelo transaccional de su producto.

12. Preguntas Frecuentes (FAQ Técnico)

Benchmarks Relacionados de Infraestructura y Bases de Datos

Consulte nuestros análisis comparativos de arquitectura de datos en profundidad: