Las bases de datos se están moviendo al Edge — Turso, Neon y Cloudflare D1 están reescribiendo dónde viven tus datos

Durante la mayor parte de la historia de las bases de datos, la pregunta de dónde vive tu base de datos ha tenido una respuesta simple: en un centro de datos, probablemente una o dos regiones por redundancia, accesible a tus servidores de aplicaciones a través de una red privada rápida. La base de datos es central. Todo se conecta a ella. La latencia entre tu aplicación y tu base de datos se mide en saltos de red de submilisegundos dentro de la misma instalación.

El problema con este modelo es que no tiene en cuenta dónde están tus usuarios. Si tus servidores de aplicaciones están en us-east-1 y un usuario en Singapur hace una solicitud, esa solicitud viaja desde Singapur a Virginia y viceversa — aproximadamente 200 milisegundos de latencia de ida y vuelta antes de que siquiera pienses en consultas a la base de datos. Las plataformas modernas Serverless y los Edge Runtimes han acercado el código de la aplicación a los usuarios: Cloudflare Workers se ejecuta en más de 300 ubicaciones, Vercel Edge Functions se despliega en docenas de regiones. Pero la mayoría de las aplicaciones aún consultan una única instancia de Postgres o MySQL ubicada en una región, eliminando el beneficio de latencia de la ejecución en el Edge en el momento en que se realiza una llamada a la base de datos.

Las bases de datos Edge intentan resolver esto moviendo los datos en sí — o al menos los datos accedidos con frecuencia — más cerca de los usuarios.

Los principales contendientes

Turso está construido sobre libSQL, un Fork de SQLite con Replication añadida. La arquitectura es sencilla: una base de datos primaria almacena la copia autorizada de tus datos, y Turso la replica automáticamente a ubicaciones Edge cercanas a tus usuarios. Las consultas de lectura llegan a la Replica más cercana; las escrituras van a la primaria. Turso ha desplegado réplicas Edge en docenas de regiones y hace que todo parezca una conexión SQLite estándar desde la perspectiva del desarrollador. El modelo de precios es agresivo — un generoso plan gratuito, luego precios por base de datos. Para aplicaciones con muchos inquilinos aislados (productos SaaS donde cada cliente tiene su propia base de datos), el modelo de Turso es convincente: puedes tener miles de bases de datos por muy poco dinero, cada una ubicada cerca de su usuario principal.

Neon adopta un enfoque diferente: es Postgres Serverless, con almacenamiento y cómputo separados. El cómputo se escala a cero cuando no se usa (eliminando costos inactivos) y escala en segundos cuando llega tráfico. La capa de almacenamiento es duradera, multiinquilino y replicada globalmente a nivel de bloque. Las réplicas de lectura se pueden desplegar en cualquier región. La experiencia del desarrollador es muy cercana a Postgres estándar — cadenas de conexión, psql, todas las herramientas habituales funcionan — lo que reduce significativamente la fricción de migración. La función de Branching de Neon, que crea instantáneas Copy-on-Write de tu base de datos para desarrollo o pruebas, ha sido ampliamente elogiada.

Cloudflare D1 también está basado en SQLite y profundamente integrado con Cloudflare Workers. La propuesta es simple: tu script Worker se ejecuta en el Edge, y D1 está justo ahí con él. Para consultas que no requieren consistencia global, D1 elimina por completo el viaje de ida y vuelta a una base de datos central. D1 actualmente tiene características limitadas en comparación con un Postgres completo — sin soporte de clave foránea listo para usar, limitado al sistema de tipos de SQLite — pero es genuinamente rápido para lecturas cuando está ubicado junto con el Worker Edge que maneja la solicitud.

PlanetScale merece una mención por una razón diferente: anunció en 2024 que estaba finalizando su plan gratuito y reenfocándose en clientes empresariales. Varios desarrolladores que habían construido proyectos en el servicio compatible con MySQL de PlanetScale se apresuraron a migrar, y muchos terminaron en Neon o Turso. La arquitectura basada en Vitess de PlanetScale ofrecía escalado horizontal a un precio que resultó ser insostenible. El episodio fue un recordatorio útil de que los servicios de bases de datos gratuitos no son una base garantizada.

El problema de la consistencia

Las bases de datos Edge hacen una concesión real: distribuir datos para lecturas de baja latencia hace que la consistencia fuerte sea más difícil de garantizar. Este no es un problema nuevo — el teorema CAP ha sido un pilar de la educación en sistemas distribuidos durante dos décadas — pero se vuelve concreto en los diseños de bases de datos Edge de maneras que vale la pena entender.

Con las réplicas Edge de Turso, una escritura confirmada en la primaria puede tardar unos cientos de milisegundos en propagarse a todas las réplicas Edge. Si un usuario escribe datos y los lee inmediatamente, y la lectura llega a una réplica que aún no ha recibido la escritura, ve datos obsoletos. Para muchas aplicaciones — un blog, un catálogo de productos, un feed social — esto es aceptable. Para aplicaciones donde la consistencia es crítica — una transacción financiera, una actualización de inventario con restricciones estrictas — no lo es.

Neon maneja esto de manera diferente. Sus réplicas de lectura se pueden configurar como síncronas (consistentes garantizadas) o asíncronas (menor latencia, potencialmente obsoletas). La mayoría de las aplicaciones pueden usar réplicas asíncronas para rutas de mucha lectura y enrutar escrituras y lecturas sensibles a la latencia a la primaria. La arquitectura es más flexible que la de Turso pero requiere un pensamiento más explícito sobre qué consultas necesitan qué nivel de consistencia.

El modelo de consistencia de Cloudflare D1 está limitado a una sola región: las escrituras en D1 son inmediatamente visibles para las lecturas en la misma región, pero no se garantiza la consistencia global. Los Durable Objects de Cloudflare proporcionan un primitivo diferente para el estado globalmente consistente, pero Durable Objects no son una base de datos relacional.

La convergencia hacia SQLite

Un patrón llamativo en el panorama de bases de datos Edge es cuántos de estos productos convergen en SQLite como su motor de almacenamiento subyacente. libSQL de Turso, Cloudflare D1, la base de datos integrada de Bun, y varios otros usan SQLite o un derivado. Las razones son prácticas: SQLite es extremadamente rápido para cargas de trabajo de un solo escritor, está incrustado en el proceso de la aplicación (sin servidor separado), y está extraordinariamente bien probado. El desafío siempre ha sido la Replication, que SQLite estándar no soporta — libSQL, LiteFS y proyectos similares están trabajando para llenar ese vacío.

La aparición de SQLite como un motor de base de datos de producción serio — más allá de su papel tradicional como almacén local incrustado — es una de las tendencias de infraestructura más interesantes de los últimos años. Se ejecuta en todo, desde dispositivos IoT hasta funciones Serverless Edge, y su simplicidad es cada vez más una característica en lugar de una limitación.

Cuándo usarlo

Las bases de datos Edge son adecuadas para aplicaciones donde los usuarios están distribuidos globalmente, las cargas de trabajo de mucha lectura son la norma y la consistencia eventual es aceptable para la mayoría de las consultas. Los productos SaaS con bases de datos por inquilino, las plataformas de contenido con audiencias globales y los backends de API que sirven a aplicaciones móviles en muchas geografías son todos candidatos razonables.

Son menos adecuadas para aplicaciones con transacciones complejas, requisitos estrictos de consistencia entre muchos usuarios, o cargas de trabajo analíticas pesadas. Un libro mayor financiero, un sistema de inventario de comercio electrónico bajo altas escrituras concurrentes, o un almacén de datos probablemente deberían permanecer en una base de datos centralizada convencional — al menos hasta que el ecosistema de bases de datos Edge madure más.

La presión subyacente que impulsa este cambio no va a desaparecer: los usuarios esperan aplicaciones rápidas, y las aplicaciones rápidas necesitan datos cerca de los usuarios. La categoría de bases de datos Edge aún es joven, las herramientas son menos maduras que Postgres centralizado, y algunos bordes ásperos permanecen. Pero para la carga de trabajo adecuada, la mejora de la latencia es tangible y real — y así es como generalmente comienza la adopción de infraestructura.