Com construir un data warehouse: marc de decisió per a CTOs de pimes
La majoria de projectes de data warehouse es sobreingieren abans de servir un sol dashboard útil. Quan en necessites un de debò i com muntar-lo en setmanes, no trimestres.
Hem auditat desenes de projectes de data warehouse en pimes catalanes i espanyoles, i en startups Series A. El patró que mata el 80% no és l'elecció de tecnologia. És començar massa aviat, amb massa peces, abans de tenir un sol dashboard que algú faci servir.
Aquest post no és un altre tutorial de Snowflake versus BigQuery. És el marc de decisió que recorrem amb qualsevol founder, CTO o director d'operacions abans de decidir si construir el warehouse — i com fer-ho sense cremar sis mesos de runway.
Quan NO necessites un data warehouse encara
La majoria d'empreses per sota de 5M€ de facturació munten un warehouse abans de necessitar-lo. Tres senyals que hauries d'esperar:
- El teu equip decideix a partir d'una sola font avui. Una exportació de Holded, un dashboard de HubSpot, un Metabase apuntant a la base de dades de producció. Si aquesta font us arriba, no necessites warehouse — necessites que aquesta font sigui més fiable.
- Tens menys de 5 fonts de veritat. Per sota d'aquest llindar, un ETL cap a una sola base SQL és més ràpid de construir i més fàcil de mantenir que un stack de warehouse.
- Ningú a l'equip escriu SQL. Sense almenys un analista o enginyer amb perfil analític, el warehouse acaba sent programari de prestatge. Models de dbt que ningú actualitza. Dashboards de Looker en què ningú confia.
⚠️ Watch Out
Si les tres senyals descriuen la teva situació, muntar un warehouse és una distracció. Arregla la qualitat de la font única primer. Tenim un post sobre data readiness per IA que aplica també a projectes de BI.
Quan SÍ que el necessites
La senyal que tanca la decisió és concreta: no pots respondre una pregunta de negoci aquesta setmana sense creuar dos CSV a mà. Si t'ha passat més de tres vegades en l'últim mes, t'has quedat petit amb la font única.
Específicament, munta un warehouse quan tinguis:
- 5+ eines SaaS desconnectades (CRM, ERP, plataformes d'ads, suport, ecommerce).
- Una cadència de reporting que requereix el mateix encreuament manual cada setmana.
- Un analista que s'està convertint en netejador de CSVs a temps complet.
- Un cas d'IA o ML que depèn de dades creuades (predicció de churn, forecast de demanda).
El marc de decisió: quatre preguntes
Abans de triar stack, contesta aquestes en ordre. La resposta a qualsevol canvia la recomanació.
Quin és el volum diari de dades?
Si ingestes menys de 10 GB al dia, estàs al free tier de BigQuery o a prop. Snowflake té sentit per sobre. Qualsevol opció cloud-native guanya l'on-premise per a pimes el 2026 — el cost operatiu de mantenir el teu propi Postgres-as-warehouse supera el cost del servei gestionat el primer any.
Qui manté els models?
dbt és l'única resposta sostenible per a equips pime. Si no tens algú que escrigui SQL i faci control de versions, retarda el projecte. Un warehouse sense governance es converteix en un cementiri de queries trencades en sis mesos.
Quina latència necessites?
Si les decisions de negoci poden esperar 24h, ELT en batch (Fivetran o Airbyte → BigQuery → dbt) és suficient. Si necessites freshness per sota de 15 min per a una feature de client, l'arquitectura canvia — necessites ingesta en streaming, que duplica complexitat i cost.
Quina capa de BI?
Metabase és gratis, corre en una VM petita i cobreix el 90% de necessitats de pime. Looker i Power BI costen més però integren millor en ecosistemes Google i Microsoft respectivament. Evita Tableau per a pime tret que ja paguis llicència per algun altre motiu.
El camí mínim en 90 dies
La majoria de projectes de warehouse que veiem fallen perquè intenten carregar 200 taules d'origen abans de servir un sol dashboard. El camí que funciona:
Setmanes 1-2: tres fonts, tres KPIs
No cinc fonts. Tres. Les que responguin la pregunta setmanal més dolorosa. Defineix exactament tres KPIs que vols al dashboard. Anota-ho. Demana confirmació a la persona que els farà servir.
Setmanes 3-4: ELT a una taula per font
Fes servir Fivetran o Airbyte per aterrar les taules crues a BigQuery o Snowflake. Sense transformació encara. Objectiu: un esquema per font, refresc diari.
Setmanes 5-8: models dbt per als tres KPIs
Construeix només el que aquests tres KPIs necessiten. Resisteix la temptació de modelar "tot el negoci". Afegeix tests a cada columna que mostres. Si un test falla, el dashboard avisa abans de mostrar números incorrectes.
Setmanes 9-12: un dashboard, un usuari, ús real
Un sol dashboard, tres KPIs, un usuari. Itera segons el que aquell usuari fa de debò amb ell. La majoria d'equips descobreix en aquest punt que estaven construint el KPI equivocat.
Després de 90 dies, amb un dashboard aportant valor, pots expandir. Sense aquesta àncora, expandir és com es construeix un warehouse que ningú fa servir.
L'stack per defecte per a pimes
Per a pime catalana i espanyola, i Series A per sota de 30M€ de facturació, l'stack avorrit funciona:
| Capa | Opció per defecte | Quan canviar |
|---|---|---|
| Warehouse | BigQuery (€) | Snowflake si necessites multi-regió o cost predictible estricte |
| Ingesta | Airbyte (open source) | Fivetran si necessites 200+ connectors a punt |
| Transformació | dbt Core (gratis) | dbt Cloud només si tens ≥3 analistes |
| BI | Metabase (gratis, self-hosted) | Looker si ets Google Workspace, Power BI si ets Microsoft |
| Orquestració | dbt Cloud o GitHub Actions | Airflow només a partir de 2M€ de data ops |
Cost mensual total de l'stack per defecte a escala pime: menys de 500€/mes incloent BigQuery, Airbyte Cloud (o self-hosted) i una VM petita per a Metabase. L'estalvi respecte a l'stack enterprise (Snowflake + Fivetran + Looker) sol ser 5-10x a aquesta escala, sense gap de capacitat per a les workloads que les pimes executen de debò.
Errors comuns (per ordre de freqüència)
- Modelar abans de saber les preguntes. Construir 50 models dbt sense consumidor downstream. Símptoma: el warehouse existeix però cap dashboard el fa servir.
- Cap test. Els números del dashboard se separen poc a poc de la realitat. La confiança s'erosiona. En sis mesos la gent torna a exportar CSVs.
- Oblidar la governance. Dos analistes, tres definicions de "client actiu". Arregla-ho la setmana 1 amb un glossari de negoci compartit, no la setmana 50.
- Comprar eines per a problemes que no tens. Una plataforma de reverse ETL quan ni tan sols tens l'ETL bàsic. dbt Cloud quan només tens un analista.
- No pressupostar el manteniment. L'stack consumeix hores per setmana fins i tot després del launch. Pressuposta 0,2-0,5 FTE permanents, o un partner fraccional.
🎯 Key Takeaway
Un data warehouse és la decisió correcta quan estàs fent el mateix encreuament manual de CSVs cada setmana per respondre una pregunta de negoci. És la decisió equivocada quan encara no has servit un sol dashboard des de la teva font actual. Munta'l només quan la pregunta dolorosa sigui repetible, fes-ho de manera mínima, i entrega un dashboard abans d'expandir.
Per on començar
Si no tens clar si estàs al grup "esperar" o "construir", els 30 minuts més barats que gastaràs són una conversa amb algú que ha muntat aquest stack 20 vegades. Ho fem com a Diagnòstic Flash gratis — l'entregable és un document d'una pàgina amb els teus 3 quick wins, no una trucada comercial.
Si ja vas començar i el projecte està encallat, l'auditoria en profunditat va més enllà: revisió completa de la teva arquitectura actual, governance i capacitat de l'equip, amb un roadmap a 180 dies.
Per al treball d'implementació a més llarg termini — muntar el warehouse amb tu — mira la nostra pàgina de serveis d'IA i dades o el post sobre serveis de pipelines ETL per a la part d'ingesta específicament.
Serveis Relacionats
Articles Relacionats
Vols parlar sobre aquest tema?
Reserva una sessió d'estratègia gratuïta amb el nostre equip.
Reservar Trucada