La solución óptima de BD para que las pymes construyan SaaS en la era del vibe coding — Cloudflare D1 × single-tenant rompe el muro de costos de la BD

La IA ha llevado el costo de “construir funcionalidades” prácticamente a cero. Incluso un equipo pequeño puede lanzar las mismas funcionalidades que una gran empresa, a la misma velocidad. Y aun así, en el momento de publicar el servicio, te topas con el muro del “costo fijo de la infraestructura” — sobre todo el costo de mantener una base de datos dedicada como AWS RDS.

Romper ese muro de frente con Cloudflare D1 y una estrategia single-tenant “un cliente, una BD”. Creo que ese es hoy el camino más corto para que una pyme opere un SaaS a gran escala.

La era de “meter a todo el mundo en una sola BD” se acabó

Hasta ahora, los SaaS a gran escala han elegido la multi-tenencia (todos los clientes compartiendo una única RDB gigantesca) prácticamente por una sola razón: los costos fijos de RDS y Aurora eran tan altos que solo compartiendo se podía hacer rentable.

Pero compartir siempre tiene un precio.

• Caldo de cultivo para incidentes de seguridad: basta con olvidar un WHERE tenant_id = ? para que los datos de otra empresa se mezclen en la respuesta. Por mucho que se afinen las revisiones, ese riesgo nunca llega a cero.
• Problema del vecino ruidoso: cuando las consultas de un cliente enorme atascan la BD, todas las demás empresas, sin tener nada que ver, se ralentizan junto a él.
• Dificultad para aprovechar la IA: cuando quieres pasarle a un RAG “solo los datos de este cliente”, la lógica para extraerlos de manera segura desde una BD donde todos están mezclados resulta mucho más pesada de lo que parece. Ya han ocurrido casos reales de prompt injection que alcanzan datos de otras empresas.

Esta estructura no es algo que debamos arrastrar tal cual a una era en la que la IA puede construir cualquier cosa.

Cloudflare D1 cambia las premisas de la infraestructura

D1 es una BD relacional serverless basada en SQLite, distribuida en el edge de Cloudflare. ¿Qué cambia para quien produce SaaS en serie?

• El costo fijo es prácticamente cero: no se paga por BDs ociosas. Aunque tengas 100 BDs encendidas “por si acaso”, mientras estén vacías no te cobran.
• Las BDs se pueden crear dinámicamente: cada nuevo contrato se convierte en una sola llamada a la API que levanta “una D1 dedicada para ese cliente”. Si intentaras lo mismo en RDS, lo primero que recibirías sería un regaño de contabilidad.
• Continuidad total con Workers: el acceso desde un Worker es, en términos de red, prácticamente cero saltos. La lectura multirregión viene de serie.

Una arquitectura single-tenant que antes era “demasiado lujosa para intentarla” se convierte en la opción por defecto sobre D1.

La ventaja abrumadora del single-tenant (un cliente, una BD)

Cuando una pyme se enfrenta a un gran proveedor, esta arquitectura se convierte directamente en argumento de venta.

Puedes decir “están aisladas físicamente”

En las negociaciones de SaaS B2B, lo primero que pregunta el departamento de TI o el área legal es: “¿nuestros datos están separados de los de otras empresas?”. Con multi-tenant solo puedes decir “están separados lógicamente”; con single-tenant puedes responder de inmediato: “los archivos de la BD en sí son diferentes”. Eso impacta directamente en la velocidad de cierre del contrato.

La IA / RAG se vuelve enormemente más simple

Si la BD está separada por cliente, el alcance de lo que puede leer la IA queda físicamente fijado desde el principio.

• Basta con decir “lee solo la BD de este cliente”.
• Las consultas que cruzan a datos de otras empresas son estructuralmente imposibles.
• La precisión de búsqueda también sube, porque hay menos ruido.

Antes que pelearse para imponer la separación de permisos del RAG dentro de una BD multi-tenant, separar primero las BDs sale más rápido al final.

Portabilidad de los datos

Cuando un cliente te dice “voy a cancelar, devuélveme mis datos”, basta con entregarle un único archivo SQLite y listo. No hace falta improvisar un batch de exportación cada vez. Un SaaS con una buena experiencia de cancelación también suele tener una alta tasa de recontratación — esa es mi observación personal.

Las desventajas y la “determinación” que hace falta para superarlas

Por supuesto, no es una bala de plata. Producir single-tenant en serie tiene sus propias dificultades.

La automatización de migraciones es obligatoria

“Añadir una columna a 1.000 BDs a la vez” se convierte en una operación cotidiana. El trabajo manual es imposible desde el primer día — necesitas tener tu propio runner de migraciones, con rollback y reintento incluidos. Aunque dejes que la IA lo escriba, esta es la capa en la que un humano hace, sí o sí, la revisión final.

El análisis transversal exige un pipeline aparte

Cuando te piden “dame los activos mensuales de todos los clientes”, lanzar SQL una por una contra 1.000 D1s no es realista.

• ETL desde cada D1 hacia una BD analítica (DuckDB, BigQuery, ClickHouse, etc.).
• La agregación se hace en ese lado.

En resumen, es un diseño que separa OLTP y OLAP desde el principio. En multi-tenant es fácil caer en la tentación de “hacer ambas cosas en la misma BD”; el single-tenant te empuja a la fuerza hacia la estructura correcta.

El “plan de graduación” para clientes que crecen demasiado

Incluso en la era single-tenant, una BD puede alcanzar el límite de capacidad o de QPS. Hay que diseñar desde el principio una arquitectura en la que solo a ese cliente se le pueda extraer hacia otra infraestructura (una D1 dedicada, o una RDS con otra configuración, etc.). En concreto: siempre intercalar una capa que resuelva “ID del tenant → ¿a qué BD me conecto?”.

Quien domine la infraestructura, dominará el SaaS de la era de la IA

En un mundo donde el costo de “construir” desaparece, lo que decide la victoria es “hasta qué punto puedes seguir operando con bajo costo, de forma segura y escalable”.

Apilar funcionalidades de IA encima mientras sigues atado a los costos fijos de un RDS pesado no va a sanear la estructura de ingresos. Producir BDs en serie sobre Cloudflare D1 y entregar valor optimizado por cliente, acompañado de la tranquilidad del single-tenant. Creo que esta combinación es el equipamiento más realista para que una pyme pueda decir, con propiedad, que opera un SaaS a gran escala.

En Wired & Eco S.A. ofrecemos asesoría en desarrollo y migración de SaaS partiendo de esta arquitectura. Ya sea para estudiar la transición de un SaaS multi-tenant existente a single-tenant, diseñar la migración a D1 o planear la operación de migraciones a escala, no dudes en escribirnos.