Turso llegó a San Pablo: qué cambia para las apps de Latinoamérica

El 1 de octubre de 2026 Turso Cloud sumó cuatro regiones nuevas, y una de ellas es San Pablo, Brasil (aws-sa-east-1). Según Turso, una app que corre en esa misma región pasa de unos 115 ms de ida y vuelta hasta el norte de Virginia a cerca de 1 ms contra su base. Para proyectos con usuarios en Argentina y el resto de Latinoamérica es la primera opción de Turso Cloud en la región, y vale la pena entender bien qué cambia y qué no.

Este es el segundo post de "Turso en español", la serie de Mark-Co Digital. Si todavía no sabés qué es Turso, empezá por la guía introductoria.

Qué anunció Turso#

El anuncio, firmado por Glauber Costa, agrega Sídney, San Pablo, Canadá Central y Estocolmo. Con eso Turso Cloud queda en diez regiones de AWS:

San Pablo es, por ahora, la única región de Turso Cloud en Latinoamérica. No hay región en Argentina, Chile ni México.

La idea detrás del anuncio la resume el propio Costa: Turso Cloud existe para que cada agente, usuario o cliente tenga su propia base, y esa base tiene que estar en la misma región que la aplicación que la usa.

De 115 ms a 1 ms: qué mide exactamente esa cifra#

• Lo que mide: el tiempo de ida y vuelta entre tu aplicación y su base de datos. Si tu backend corre en San Pablo y tu base estaba en Virginia, cada consulta cruzaba el continente, unos 115 ms según Turso. Con la base en la misma región, Turso habla de alrededor de 1 ms.
• Lo que no mide: la latencia entre el navegador o el celular de tu usuario y tu servidor. Eso depende de dónde esté alojado tu backend y de la red de cada usuario.

El beneficio aparece cuando backend y base están en la misma región. Si tu servidor sigue en Estados Unidos y movés solo la base a San Pablo, podés terminar peor que antes. Y como una página suele hacer varias consultas por pedido, la diferencia entre 115 ms y 1 ms se multiplica en cada carga.

Cómo guarda los datos: arquitectura sin discos#

Junto con las regiones, el anuncio explica cómo funciona el almacenamiento. Turso Cloud escribe el registro de escritura anticipada (el WAL, donde SQLite anota cada cambio antes de consolidarlo) en S3 Express One Zone, un servicio de almacenamiento de AWS, y después lo compacta hacia S3 estándar de forma asíncrona.

Turso ya había contado este diseño "sin discos" en abril de 2025, en un post sobre cómo Turso Cloud dejaba de depender de discos locales. La documentación de durabilidad agrega dos datos útiles:

• Durabilidad: 99,999999999% en todos los planes, según la documentación.
• Latencia extra máxima por commit, que depende del plan, porque los commits de distintas bases se agrupan antes de escribirse:

El "1 ms" del anuncio es el viaje de red dentro de la región; en escrituras, el plan define cuánto puede esperar un commit para agruparse con otros. Si tu aplicación hace muchas escrituras pequeñas y seguidas, tenelo en cuenta al elegir plan.

En disponibilidad, el balance de un año del proyecto (marzo de 2026) informaba 100% en todas las regiones durante los 90 días previos, según la propia Turso.

Residencia de datos: elegir dónde vive cada base#

La página de soberanía de datos de Turso plantea que la residencia pasa a ser una propiedad que definís por base, y no un despliegue separado que tenés que operar. Esa misma página menciona SOC 2 Type II, GDPR, HIPAA y la opción de llevar Turso a tu propia nube (BYOC). En el anuncio de la nueva generación de Turso Cloud, todavía en beta privada en abril de 2026, BYOC se describe como mantener datos y cómputo dentro de tu cuenta de AWS.

Con San Pablo disponible, un proyecto latinoamericano que necesite tener los datos en la región ya tiene una opción dentro de Turso Cloud. Eso no reemplaza el análisis legal de tu caso: si manejás datos personales con requisitos específicos, la decisión de dónde alojarlos la tenés que validar con tu asesor.

Cómo elegir región en la práctica#

En Turso Cloud las bases se organizan en grupos, y cada grupo tiene una ubicación primaria. Según la documentación del comando de creación de grupos, si no indicás ubicación se elige la región más cercana a vos, y podés forzarla con --location.

turso group create <group-name> [flags]

Antes de decidir, podés listar las ubicaciones disponibles. Con la opción -l (o --show-latencies) la CLI muestra la latencia desde tu máquina hasta cada una:

turso db locations

Dos detalles a tener en cuenta:

• Varios grupos requieren plan Scaler o superior. Si estás en Free o Developer, elegí bien la ubicación desde el principio.
• Medí desde donde corre tu backend, no solo desde tu notebook. La latencia que importa es la de tu servidor.

Qué pasó con las réplicas en el borde#

Si leíste material viejo sobre Turso, vas a encontrar "edge replicas": copias de la base repartidas por el mundo. Esa función está deprecada para usuarios nuevos; quienes ya la usaban pueden seguir haciéndolo en Fly. En el post de enero de 2025 Turso explicó que el 70% de sus usuarios nunca creaba réplicas geográficas.

La estrategia actual es otra: una base en la región correcta y, si necesitás lecturas instantáneas cerca del usuario, llevar la base al dispositivo o al servidor. Para eso existen las réplicas embebidas de libSQL y, para proyectos nuevos, Turso Sync, que la documentación recomienda por sobre las réplicas embebidas. Las dos opciones las vamos a ver en detalle más adelante en la serie.

Qué significa para tu proyecto#

Si tenés o estás planificando una app para usuarios de Argentina o de la región, estas son las decisiones concretas:

1. Alineá backend y base. Si tu backend corre en AWS San Pablo, o en un proveedor con presencia en esa zona, tener la base de Turso ahí mismo es donde aparece la mejora de latencia.
2. Revisá tu plan pensando en escrituras. La latencia máxima agregada al commit cambia de 100 ms en Free a 10 ms en Pro.
3. Pensá la región antes de crecer. Si vas a tener una base por cliente, decidí dónde vive cada grupo desde el diseño.
4. Si tus usuarios trabajan con mala conexión, la región ayuda, pero lo que resuelve el problema es una base local con sincronización.

Para una pyme, la regla es simple: antes de contratar una base administrada, preguntá dónde va a estar físicamente y dónde va a estar tu servidor. Lo mismo aplica a otras plataformas; en nuestro resumen semanal de novedades de Supabase seguimos cómo evoluciona ese ecosistema.

Preguntas frecuentes#

¿Hay una región de Turso Cloud en Argentina?#

No. Según el anuncio del 1 de octubre de 2026, la única región en Latinoamérica es San Pablo. Las otras nueve están en Norteamérica, Europa, Asia y Oceanía.

¿Puedo pasar una base que ya tengo en otra región a San Pablo?#

En la documentación que revisamos no encontramos un comando para mover una base existente de región. La vía documentada que sí existe es exportar con .dump y volver a cargar el SQL en una base nueva creada en un grupo de la región que quieras:

turso db shell <database-name> .dump > dump.sql

turso db shell <database-name> < dump.sql

Hacelo primero con una copia y planificá una ventana sin escrituras.

¿Me conviene mover la base si mi servidor está en Estados Unidos?#

En general no, porque la cifra de 1 ms aplica cuando la aplicación y la base comparten región. Si tu backend sigue en Estados Unidos, cada consulta tendría que cruzar el continente hacia San Pablo. Lo razonable es mover los dos juntos o ninguno.

¿Las réplicas embebidas reemplazan a una región cercana?#

Resuelven otro problema. Una réplica embebida guarda una copia local para leer sin pasar por la red, pero las escrituras van por defecto a la base remota. La región define qué tan rápido llegan esas escrituras y las consultas del backend.

Si estás evaluando dónde alojar la base de datos de tu proyecto y cómo reducir la latencia para usuarios latinoamericanos, en Mark-Co Digital te ayudamos a diseñar la infraestructura cloud y a comparar opciones como Turso y Supabase según tu caso.

Fuentes#

• Turso Cloud now runs in Australia, Brazil, Canada, and Sweden, de Glauber Costa
• Durabilidad en Turso Cloud (documentación)
• Turso Cloud goes diskless
• Soberanía de datos en Turso
• Comando turso group create
• Comando turso db locations
• Edge replicas (deprecadas)
• Upcoming changes to the Turso platform and roadmap, de Glauber Costa
• Réplicas embebidas (documentación)
• Uso de Turso Sync (documentación)
• La nueva generación de Turso Cloud en beta privada, de Glauber Costa
• We are a year into rewriting SQLite, de Glauber Costa
• Comando turso db shell
• Novedades de Supabase, semana del 30/9 al 6/10/2026 (Mark-Co Digital)