Cómo construir un data warehouse: marco de decisión para CTOs de pymes
La mayoría de proyectos de data warehouse se sobreingieren antes de tener un solo dashboard útil. Cuándo necesitas uno de verdad y cómo montarlo en semanas, no trimestres.
Hemos auditado decenas de proyectos de data warehouse en pymes españolas y startups Series A. El patrón que mata el 80% de ellos no es la elección de tecnología. Es arrancar demasiado pronto, con demasiadas piezas, antes de tener un solo dashboard que alguien use.
Este post no es otro tutorial de Snowflake versus BigQuery. Es el marco de decisión que recorremos con cualquier founder, CTO o director de operaciones antes de decidir si construir el warehouse — y cómo hacerlo sin quemar seis meses de runway.
Cuándo NO necesitas un data warehouse todavía
La mayoría de empresas por debajo de 5M€ de facturación construyen un warehouse antes de necesitarlo. Tres señales de que deberías esperar:
- Tu equipo decide a partir de una sola fuente hoy. Una exportación de Holded, un dashboard de HubSpot, un Metabase apuntando a tu base de datos de producción. Si esa fuente os llega, no necesitas warehouse — necesitas que esa fuente sea más fiable.
- Tienes menos de 5 fuentes de verdad. Por debajo de ese umbral, un ETL hacia una sola base SQL es más rápido de construir y más fácil de mantener que un stack de warehouse.
- Nadie en el equipo escribe SQL. Sin al menos un analista o ingeniero con perfil analítico, el warehouse acaba siendo software de adorno. Modelos de dbt que nadie actualiza. Dashboards de Looker en los que nadie confía.
⚠️ Watch Out
Si las tres señales describen tu situación, montar un warehouse es una distracción. Arregla la calidad de tu fuente única primero. Tenemos un post sobre data readiness para IA que aplica también a proyectos de BI.
Cuándo SÍ lo necesitas
La señal que cierra la decisión es concreta: no puedes responder una pregunta de negocio esta semana sin cruzar dos CSV a mano. Si te ha pasado más de tres veces en el último mes, te has quedado pequeño con tu fuente única.
Específicamente, monta un warehouse cuando tengas:
- 5+ herramientas SaaS desconectadas (CRM, ERP, plataformas de ads, soporte, ecommerce).
- Una cadencia de reporting que requiere el mismo cruce manual cada semana.
- Un analista que se está convirtiendo en limpiador de CSVs a tiempo completo.
- Un caso de IA o ML que depende de datos cruzados (predicción de churn, forecast de demanda).
El marco de decisión: cuatro preguntas
Antes de elegir stack, contesta estas en orden. La respuesta a cualquiera de ellas cambia la recomendación.
¿Cuál es el volumen diario de datos?
Si ingiestas menos de 10 GB al día, estás en el free tier de BigQuery o cerca. Snowflake tiene sentido por encima. Cualquier opción cloud-native gana al on-premise para pymes en 2026 — el coste operativo de mantener tu propio Postgres-as-warehouse supera el coste del servicio gestionado en el primer año.
¿Quién mantiene los modelos?
dbt es la única respuesta sostenible para equipos pyme. Si no tienes a alguien que escriba SQL y use control de versiones, retrasa el proyecto. Un warehouse sin governance se convierte en un cementerio de queries rotas en seis meses.
¿Qué latencia necesitas?
Si las decisiones de negocio pueden esperar 24h, ELT en batch (Fivetran o Airbyte → BigQuery → dbt) es suficiente. Si necesitas freshness por debajo de 15 min para una feature de cliente, la arquitectura cambia — necesitas ingestión en streaming, que duplica complejidad y coste.
¿Qué capa de BI?
Metabase es gratis, corre en una VM pequeña y cubre el 90% de necesidades de pyme. Looker y Power BI cuestan más pero integran mejor en ecosistemas Google y Microsoft respectivamente. Evita Tableau para pyme salvo que ya pagues licencia por otro motivo.
El camino mínimo en 90 días
La mayoría de proyectos de warehouse que vemos fallan porque intentan cargar 200 tablas origen antes de servir un solo dashboard. El camino que funciona:
Semanas 1-2: tres fuentes, tres KPIs
No cinco fuentes. Tres. Las que respondan la pregunta semanal más dolorosa. Define exactamente tres KPIs que quieres en el dashboard. Anótalos. Pídele firmar a la persona que los va a usar.
Semanas 3-4: ELT a una tabla por fuente
Usa Fivetran o Airbyte para aterrizar las tablas crudas en BigQuery o Snowflake. Sin transformación todavía. Objetivo: un esquema por fuente, refresco diario.
Semanas 5-8: modelos dbt para los tres KPIs
Construye solo lo que esos tres KPIs necesitan. Resiste la tentación de modelar "todo el negocio". Añade tests en cada columna que muestres. Si un test falla, el dashboard avisa antes de mostrar números equivocados.
Semanas 9-12: un dashboard, un usuario, uso real
Un solo dashboard, tres KPIs, un usuario. Itera según lo que ese usuario hace de verdad con él. La mayoría de equipos descubre en este punto que estaban construyendo el KPI equivocado.
Tras 90 días, con un dashboard aportando valor, puedes expandir. Sin ese ancla, expandir es cómo se construye un warehouse que nadie usa.
El stack por defecto para pymes
Para pyme española y Series A por debajo de 30M€ de facturación, el stack aburrido funciona:
| Capa | Opción por defecto | Cuándo cambiar |
|---|---|---|
| Warehouse | BigQuery (€) | Snowflake si necesitas multi-región o coste predecible estricto |
| Ingestión | Airbyte (open source) | Fivetran si necesitas 200+ conectores listos |
| Transformación | dbt Core (gratis) | dbt Cloud solo si tienes ≥3 analistas |
| BI | Metabase (gratis, self-hosted) | Looker si eres Google Workspace, Power BI si eres Microsoft |
| Orquestación | dbt Cloud o GitHub Actions | Airflow solo a partir de 2M€ de data ops |
Coste mensual total del stack por defecto a escala pyme: menos de 500€/mes incluyendo BigQuery, Airbyte Cloud (o self-hosted) y una VM pequeña para Metabase. El ahorro respecto al stack enterprise (Snowflake + Fivetran + Looker) suele ser 5-10x a esta escala, sin gap de capacidad para las workloads que las pymes ejecutan de verdad.
Errores comunes (por orden de frecuencia)
- Modelar antes de saber las preguntas. Construir 50 modelos dbt sin consumidor downstream. Síntoma: el warehouse existe pero ningún dashboard lo usa.
- Ningún test. Los números del dashboard se separan poco a poco de la realidad. La confianza se erosiona. En seis meses la gente vuelve a exportar CSVs.
- Olvidar la governance. Dos analistas, tres definiciones de "cliente activo". Arregla esto en la semana 1 con un glosario de negocio compartido, no en la semana 50.
- Comprar herramientas para problemas que no tienes. Una plataforma de reverse ETL cuando ni siquiera tienes el ETL básico. dbt Cloud cuando solo hay un analista.
- No presupuestar el mantenimiento. El stack consume horas por semana incluso después del launch. Presupuesta 0,2-0,5 FTE permanentes, o un partner fraccional.
🎯 Key Takeaway
Un data warehouse es la decisión correcta cuando estás haciendo el mismo cruce manual de CSVs cada semana para responder una pregunta de negocio. Es la decisión equivocada cuando todavía no has servido un solo dashboard desde tu fuente actual. Móntalo solo cuando la pregunta dolorosa sea repetible, hazlo de forma mínima, y entrega un dashboard antes de expandir.
Por dónde empezar
Si no tienes claro si estás en el grupo "esperar" o "construir", los 30 minutos más baratos que vas a gastar son una conversación con alguien que ha montado este stack 20 veces. Lo hacemos como Diagnóstico Flash gratis — el entregable es un documento de una página con tus 3 quick wins, no una llamada comercial.
Si ya empezaste y el proyecto está atascado, la auditoría en profundidad va más allá: revisión completa de tu arquitectura actual, governance y capacidad del equipo, con un roadmap a 180 días.
Para el trabajo de implementación a más largo plazo — montar el warehouse contigo — mira nuestra página de servicios de IA y datos o el post sobre servicios de pipelines ETL para la parte de ingesta específicamente.
Servicios Relacionados
Artículos Relacionados
¿Quieres hablar sobre este tema?
Reserva una sesión de estrategia gratuita con nuestro equipo.
Reservar Llamada