Una base de datos por cliente: multi-tenancy con Turso para tu SaaS

Multi-tenancy con una base por cliente significa que cada cliente de tu SaaS tiene su propia base de datos, separada de las demás, en lugar de compartir tablas con una columna que indica a quién pertenece cada fila. Turso defiende este modelo porque el aislamiento lo da la arquitectura, cada cliente se puede respaldar y restaurar por separado y, con bases que son archivos, crear una nueva cuesta muy poco. A cambio, los reportes entre clientes y las migraciones de esquema se vuelven más trabajosos.

Ayer vimos la misma idea aplicada a agentes de IA. Hoy, dentro de la serie "Turso en español", la llevamos al caso más clásico: un SaaS con clientes.

La guía de Jeff Olson: "Multi-tenancy at Scale"#

En agosto de 2026 Jeff Olson publicó en el blog de Turso una guía sobre cómo darle a cada usuario su propia base. La frase que resume su postura es que crear una base de datos nunca debería ser una decisión financiera.

La guía apoya ese planteo en tres argumentos.

1. Aislamiento sin depender de políticas#

En una base compartida, la separación entre clientes depende de que cada consulta filtre bien o de que estén bien escritas las políticas de Row-Level Security (RLS), las reglas que limitan qué filas puede ver cada usuario. Un error en una política puede exponer datos de otro cliente.

Con una base por cliente, el argumento de Olson es que no hay nada que configurar mal en ese punto: la consulta de un cliente nunca llega a la base de otro. Para cumplimiento normativo, la guía menciona HIPAA y GDPR y sostiene que la garantía de aislamiento sale de la arquitectura misma.

La página de privacidad por usuario de Turso suma dos ideas:

• Cada base de usuario se cifra de forma independiente, así que una brecha en una no compromete a todas.
• Un token da acceso a la base de un solo usuario y a nada más.

2. Operaciones por cliente#

La página de soluciones para SaaS multi-tenant enumera lo que gana cada cliente con su propia base: esquema propio, residencia de datos por cliente, alta de bases por API, branching para probar migraciones y recuperación en el tiempo (PITR) por cliente.

Ese último punto es muy concreto. Si un cliente borra datos por error, restaurás solo su base a un momento anterior, sin tocar a nadie más. En Turso Cloud la restauración crea una base nueva a partir de la original:

turso db create my-new-database --from-db my-existing-database --timestamp 2024-01-01T00:00:00Z

La ventana disponible depende del plan, según la documentación de PITR:

3. Costos#

La guía incluye una comparación hecha por Turso, no independiente: 1.000 bases en AWS RDS costarían entre USD 12.000 y 50.000 por mes, frente a USD 24,92 por mes del plan Scaler de Turso (24 GB). Ese precio es el valor mensual con facturación anual que muestra la página de precios.

La comparación sirve para entender el orden de magnitud: con bases que son archivos, una base inactiva solo paga almacenamiento. Igual, para tu caso, hacé la cuenta con tu volumen real de lecturas, escrituras y almacenamiento.

Cómo se ve el ciclo de vida de un cliente#

Con una base por cliente, el alta y la baja de un cliente pasan a ser operaciones de código. La documentación de la Platform API, la API para administrar bases de Turso Cloud, muestra el flujo con el cliente @tursodatabase/api:

import { createClient } from "@tursodatabase/api";

const turso = createClient({
  org: process.env.TURSO_ORG!,
  token: process.env.TURSO_PLATFORM_TOKEN!,
});

// Alta: crear la base del cliente
const db = await turso.databases.create("user-abc123", { group: "default" });

// Generar un token que solo sirve para esa base
const { jwt } = await turso.databases.createToken("user-abc123");

// Baja: borrarla cuando ya no se necesita
await turso.databases.delete("user-abc123");

Dos detalles de la referencia que conviene saber de entrada: el nombre de la base admite solo minúsculas, números y guiones, hasta 64 caracteres, y si ya existe una base con ese nombre la API responde con un error 409.

Además, los tokens pueden tener permisos finos por tabla: por ejemplo, permitir leer y agregar datos pero no borrar ni cambiar el esquema.

Un caso real: Poke#

Jeff Olson también contó el caso de Poke, donde cada sitio web que generan los usuarios tiene su propia base. Según el caso de estudio, llegaron a unas 10.000 bases y 100 millones de mensajes en tres meses. Samyok Nepal, de Poke, explica que no querían que un solo sitio con mucho tráfico tirara abajo a todos los demás, y que con Turso eso no les pasó.

Las desventajas que la propia guía reconoce#

Lo valioso de la guía de Olson es que no la vende como solución universal. Reconoce tres costos:

• Analítica entre clientes: si querés saber cuántos pedidos hubo en total, no hay una tabla donde preguntar. Necesitás un pipeline aparte.
• Migraciones en toda la flota: cada cambio de esquema hay que aplicarlo a todas las bases y coordinarlo.
• No sirve para todo: según la guía, probablemente sea la opción equivocada para apps de consumo con millones de usuarios gratuitos y consultas constantes que cruzan datos entre usuarios.

Cómo resolver la analítica#

Turso publicó en 2024 un patrón para esto: un ETL programado que descubre las bases con la Platform API, extrae métricas de cada una y las guarda en una base central de analítica. No es complicado, pero es una pieza más que tenés que mantener.

Y las migraciones#

Turso tuvo una función de esquemas compartidos entre varias bases (multi-DB schemas), pero hoy está deprecada para usuarios nuevos. Eso significa que la coordinación de migraciones queda de tu lado. El branching ayuda: podés crear una copia de una base, probar la migración ahí y recién después aplicarla en serio.

Qué significa para tu proyecto#

Si estás armando un SaaS, por ejemplo un sistema de gestión para estudios contables o una plataforma de reservas para comercios, estas preguntas te ayudan a decidir:

• ¿Tus clientes son empresas con datos claramente separados? Si cada cliente trabaja solo con lo suyo, una base por cliente encaja muy bien.
• ¿Te piden aislamiento fuerte o restauraciones por cliente? Este modelo lo resuelve por diseño.
• ¿Necesitás reportes globales en tiempo real? Si son centrales para tu negocio, una base compartida, por ejemplo Postgres con RLS en Supabase, puede ser más simple.
• ¿Tenés capacidad para automatizar migraciones? Con cientos de bases, aplicarlas a mano no es opción.

No hay una respuesta única. Las dos empresas, de hecho, plantean que se complementan: el anuncio de Turso sobre su incorporación a Supabase habla de un camino hacia Postgres cuando SQLite no alcance. Más contexto en la guía introductoria de la serie.

Preguntas frecuentes#

¿Cómo hago reportes que crucen los datos de todos mis clientes?#

Con un proceso ETL programado: recorrés las bases con la Platform API, sacás las métricas que te interesan y las consolidás en una base central de analítica, como propone Turso en su post de 2024.

¿Cómo aplico un cambio de esquema a cientos de bases?#

Con un script o pipeline que recorra las bases y aplique la migración a cada una. Probala antes en un branch de una base real, y tené presente que la restauración en el tiempo de cada base te permite volver atrás si algo falla.

¿Una base por cliente es más segura que Row-Level Security?#

Es otro tipo de garantía. RLS depende de que las políticas estén bien escritas; una base por cliente separa físicamente los datos. La guía de Turso sostiene que así no queda nada por configurar mal, pero igual tenés que cuidar los tokens de cada base.

¿Cuándo no conviene una base por cliente?#

Cuando tus usuarios son millones de cuentas gratuitas y tu app consulta constantemente datos de unos y otros, por ejemplo una red social. La propia guía de Turso lo marca como un caso donde probablemente sea la opción equivocada.

Si estás diseñando el backend de tu SaaS y querés decidir entre una base compartida y una base por cliente, en Mark-Co Digital te ayudamos con el desarrollo backend y con la evaluación de opciones como Turso y Supabase para que la arquitectura acompañe el crecimiento.

Fuentes#

• Multi-tenancy at Scale: How to Give Every User Their Own Database, de Jeff Olson
• Turso para SaaS multi-tenant
• Privacidad por usuario en Turso
• Multi-tenancy en Turso
• Introducción a la Platform API
• Platform API: crear una base
• Permisos finos de tokens
• Point-in-time recovery (documentación)
• Branching (documentación)
• Multi-DB schemas (deprecado)
• Analytics for per-user database architecture
• How Poke Gives Every User Their Own Database, de Jeff Olson
• Precios de Turso
• Turso is joining Supabase, de Glauber Costa