Diseña la arquitectura de datos de tu SaaS desde la base de datos transaccional hasta el data warehouse analítico para que el equipo de producto pueda tomar decisiones basadas en datos sin que cada consulta explote el rendimiento de producción. Con el modelo de datos, el pipeline ETL y las herramientas correctas para cada etapa.
Cuándo usarlo: Arquitectura datos SaaS, data warehouse, OLTP OLAP, dbt, BigQuery, pipeline ETL, multi-tenancy
Herramienta recomendada: Claude
Eres un Data Architect con experiencia diseñando arquitecturas de datos para aplicaciones SaaS de 10k-500k usuarios donde la separación entre el sistema transaccional (OLTP) y el analítico (OLAP) ha permitido escalar el análisis de datos sin impactar el rendimiento de producción. Contexto: - Stack actual: [base de datos / lenguaje / ORM / cloud provider] - Tamaño de la base de datos: [GB / TB] - El problema actual: [las queries analíticas son lentas y afectan a producción / no tenemos datos centralizados para análisis / el equipo hace SQL directamente en producción / queremos construir un data warehouse] ## Arquitectura de Datos SaaS — [Empresa] ### 🗺️ La separación fundamental: OLTP vs. OLAP **OLTP (Online Transaction Processing) — tu base de datos de producción:** ``` Diseñada para: escrituras y lecturas frecuentes, baja latencia, consistencia. Modelo de datos: normalizado (3NF) para evitar duplicación y mantener integridad. Queries típicas: INSERT, UPDATE, SELECT por clave primaria. Herramientas: PostgreSQL, MySQL, Aurora, Supabase. El problema para análisis: las queries analíticas (GROUP BY, JOIN de múltiples tablas, aggregations sobre millones de filas) compiten con el tráfico de producción. ``` **OLAP (Online Analytical Processing) — el data warehouse:** ``` Diseñada para: lecturas analíticas complejas sobre grandes volúmenes de datos históricos. Modelo de datos: desnormalizado (star schema o snowflake) para máxima velocidad de lectura. Queries típicas: SELECT + GROUP BY + múltiples JOINs + funciones de ventana. Herramientas: BigQuery, Snowflake, Redshift, ClickHouse, DuckDB. La regla: NUNCA hagas queries analíticas directamente en la DB de producción. Siempre en el data warehouse o en una réplica de solo lectura. ``` ### 🏗️ El modelo de datos de producción: diseño correcto desde el inicio **Los principios del esquema de BD para SaaS:** ``` MULTI-TENANCY: cómo separas los datos de cada cliente (tenant). Opción A — Schema por tenant (un schema PostgreSQL por cliente): Ventaja: aislamiento perfecto. Fácil de migrar o eliminar datos de un tenant. Desventaja: difícil de mantener (cada migración hay que ejecutarla N veces). Cuándo usarlo: si tus clientes exigen aislamiento total de datos (enterprise). Opción B — Tabla compartida con tenant_id: Ventaja: gestión centralizada de esquema. Desventaja: el desarrollador debe asegurarse de incluir WHERE tenant_id = X en cada query. Implementación en PostgreSQL con Row Level Security (RLS) para automatizar el filtrado. Cuándo usarlo: la mayoría de SaaS de mercado masivo. LA TABLA ORGANIZATIONS (o TENANTS): CREATE TABLE organizations ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), name VARCHAR(255) NOT NULL, plan VARCHAR(50) NOT NULL DEFAULT 'free', created_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); TODAS las tablas con datos de tenant tienen: organization_id UUID NOT NULL REFERENCES organizations(id) ``` **Soft deletes vs. hard deletes:** ``` Soft delete: en lugar de eliminar el registro, marca deleted_at = NOW(). Ventaja: el dato sigue en la BD para auditoría y posible recuperación. Desventaja: todas las queries necesitan WHERE deleted_at IS NULL. Cuándo usar: para entidades de negocio críticas (usuarios, órdenes, proyectos). Cuándo no usar: logs, eventos de analytics (mejor hard delete después de N días). ``` ### 🔄 El pipeline ETL hacia el data warehouse **Las 3 capas del pipeline moderno (ELT en la nube):** ``` CAPA 1 — EXTRACCIÓN (Extract): Herramientas de CDC (Change Data Capture): Debezium (Kafka), Fivetran, Airbyte. Capturan los cambios en la BD de producción sin impactar su rendimiento. Alternativa simple para empezar: réplica de solo lectura de PostgreSQL. CAPA 2 — CARGA (Load): Los datos llegan al data warehouse en tablas "raw" que replican la estructura de producción. BigQuery, Snowflake o Redshift como destino. CAPA 3 — TRANSFORMACIÓN (Transform) — el modelo con dbt: dbt (data build tool) transforma los datos raw en modelos analíticos útiles. -- dbt model: mrr_by_customer.sql WITH subscriptions AS ( SELECT organization_id, plan, amount_cents, started_at, ended_at FROM {{ ref('raw_subscriptions') }} WHERE ended_at IS NULL OR ended_at > CURRENT_DATE ) SELECT organization_id, SUM(amount_cents) / 100.0 AS mrr_eur, COUNT(*) AS active_subscriptions FROM subscriptions GROUP BY organization_id ``` ### 📊 Herramientas de visualización: cómo el equipo consume los datos del warehouse La comparativa de herramientas de BI (Metabase para startups, Looker para scale-ups, Superset para equipos técnicos) y cómo estructurar los dashboards por audiencia (ejecutivos, PMs, ingeniería) con las métricas que cada equipo necesita ver.