El modern data stack para una empresa B2B de tamaño medio, sin hype

El modern data stack tiene un problema de marketing: los que definen "moderno" son los mismos que venden las herramientas. En algún punto entre el empleado 20 y el 500, alguien te va a poner enfrente un diagrama de arquitectura con 19 logos. Un data warehouse, una herramienta de ELT, una capa de transformación, un CDP, reverse ETL, un catálogo de datos, una capa semántica, una plataforma de observabilidad, un metrics store. Para una empresa de tu tamaño, la mayor parte de ese diagrama es teatro de procurement. Necesitas cuatro herramientas, un orden de construcción y dos personas que entiendan el sistema completo.

Ya escribimos sobre por qué tus números no cuadran. Este post es la guía de compra: qué warehouse, qué herramienta de pipelines, qué hace dbt por ti en la práctica, y las dos trampas que atrapan a los equipos de tamaño medio: comprar un CDP demasiado pronto y dejar que un solo analista se convierta en el punto único de falla.

Elige el data warehouse en una semana, no en un trimestre

BigQuery y Snowflake son excelentes, y justo por eso la evaluación no debería tomar mucho. Con los volúmenes de una empresa de tamaño medio, digamos menos de unos pocos terabytes de datos activos, las diferencias honestas se reducen a ecosistema y modelo de cobro.

BigQuery es serverless y pagas por consulta: alrededor de $6.25 por TiB escaneado bajo demanda, con el primer TiB de cada mes gratis. No hay clústeres que dimensionar ni nada que apagar en la noche. Si usas GA4, Google Ads o cualquier cosa en GCP, los exports nativos lo vuelven la opción por defecto; GA4 exporta a BigQuery sin costo adicional, y eso solo ya resuelve la decisión para muchos equipos guiados por marketing. La trampa: una herramienta de BI corriendo SELECT * sobre una tabla de eventos sin particionar puede quemarse el presupuesto del mes en una tarde. Particiona tus tablas y configura controles de gasto desde el día uno.

Snowflake cobra cómputo por segundo a través de créditos, y su modelo de warehouses te da aislamiento real de cargas: el job de ELT, los dashboards de BI y los experimentos del data scientist corren cada uno en su propio cómputo, así nadie frena a nadie. El data sharing es más fuerte y corre en AWS, Azure y GCP. La trampa a escala pequeña es pagar cómputo ocioso porque alguien dejó el auto-suspend en 10 minutos en un warehouse que corre una consulta por hora.

Entre 20 y 500 personas, cualquiera de las dos facturas queda en cientos de dólares al mes si se configura con criterio. Elige por ecosistema: si vives en Google, BigQuery; si estás cargado hacia AWS con equipos que necesitan cómputo aislado, Snowflake. Y esta es la parte que ningún vendor te va a decir: esta decisión importa mucho menos que lo que viene después. Hemos visto equipos correr una evaluación de warehouse de tres meses y luego definir "cliente activo" en un hilo de Slack. Es exactamente al revés.

Fivetran o Airbyte, la versión honesta

El ELT es plomería. Lo quieres aburrido.

Fivetran tiene los mejores conectores del mercado y pide casi cero mantenimiento. El precio se basa en filas activas mensuales, y para una lista típica de fuentes (CRM, facturación, plataformas de ads, mesa de soporte) la factura corre entre $500 y $1,500 al mes. Se encarece cuando empujas tablas de alto volumen, así que no lo hagas: los eventos de producto van por export directo al warehouse, no por un tubo que cobra por fila.

Airbyte es open source. Self-hosted cuesta infraestructura más horas de ingeniería, y las horas son reales: upgrades de conectores, sorpresas por cambios de esquema, el sync ocasional que muere un viernes. Airbyte Cloud cierra buena parte de esa brecha con precios por volumen. Elige Airbyte cuando ya tienes ingenieros de plataforma en el equipo, o cuando necesitas un conector de cola larga que Fivetran no cubre.

Nuestra recomendación por defecto: Fivetran para los primeros cinco a diez conectores, con un recordatorio en el calendario para revisar cuando la factura cruce los $2,000 al mes. Las horas de ingeniero cuidando pipelines son la línea más cara del presupuesto de datos, y nunca aparecen en la hoja de comparación de herramientas.

dbt es donde el stack se gana su lugar

El warehouse y los pipelines son commodities. La capa de transformación es donde vive la lógica real de tu empresa, y ahí dbt no es negociable.

dbt es donde "cliente", "MRR" y "closed-won" se definen una sola vez, en SQL versionado, con tests. Cuando el admin de Salesforce renombra un campo, un test de esquema falla con ruido en lugar de que una métrica de directorio se desvíe en silencio. Cuando finanzas y marketing discuten el CAC, la discusión se resuelve en un pull request y no en una reunión. Tu sistema de RevOps es tan confiable como esas definiciones.

dbt Core es gratuito. dbt Cloud cuesta cerca de $100 por desarrollador al mes y te da scheduling y documentación hospedada. Un proyecto realista para una empresa de tamaño medio son 40 a 120 modelos, y un analytics engineer competente deja los primeros marts de revenue y pipeline en producción en cuatro a seis semanas.

Casi seguro no necesitas un CDP

El CDP es el producto más sobrevendido del data stack para una empresa de entre 20 y 500 personas. El pitch suena muy bien: captura cada evento una sola vez, unifica identidades, enruta datos a donde sea en tiempo real. La realidad para una empresa B2B con un producto, un sitio web y cinco destinos es que tu warehouse ya hace eso, menos la capa de tiempo real que probablemente no necesitas y la factura anual de cinco cifras que definitivamente no.

El patrón warehouse-first lo cubre: manda los eventos de producto directo a BigQuery o Snowflake, modela identidad en dbt, y cuando un equipo necesite datos dentro de HubSpot o de una plataforma de ads, agrega una herramienta de reverse ETL como Census o Hightouch para ese caso puntual. Cada sync que agregas se justifica por un flujo de trabajo real, no por una licencia de plataforma.

Un CDP se gana su lugar cuando tienes varios productos de cara al cliente, personalización en tiempo real entre web, email y ads, y un equipo de growth engineering que lo alimente. Debajo de 500 personas, eso casi no describe a nadie. Compra el caso de uso, no la categoría.

El dashboard de una sola persona, y el orden de construcción que lo evita

La falla más común que vemos en datos de empresas de tamaño medio no es una herramienta. Es una persona: el analista que construyó los 60 dashboards, tiene cada definición de métrica en la cabeza y escribió el SQL directo dentro de la herramienta de BI. Cuando se va, y se va, los números se congelan. Nadie se atreve a tocar un dashboard que no puede reconstruir, la confianza se degrada en un trimestre y el equipo directivo vuelve en silencio a las hojas de cálculo. Ese es el bus factor en su versión más cara.

El arreglo es estructural, no heroico. La lógica de métricas vive en dbt, versionada y revisada. La capa de BI se queda delgada: Metabase o Looker Studio leyendo de tablas modeladas, no consultas de 400 líneas pegadas en editores de gráficos. Dos personas, mínimo, pueden correr cada pipeline de punta a punta. Hay un runbook. Si son 30 personas y no puedes justificar dos contrataciones de datos, la segunda persona puede ser fraccional, pero un bus factor de uno es una decisión, y es la equivocada.

El orden de construcción que funciona, una y otra vez:

Semanas 1-2: levanta el warehouse y conecta CRM, facturación y eventos de producto. Semanas 3-6: modelos de dbt para revenue y pipeline, con tests, revisados por finanzas y sales ops. Semanas 7-8: dashboards para dirección, ventas y marketing, leyendo solo de tablas modeladas. Después: orquestación, alertas y fuentes nuevas de una en una.

Herramientas todo incluido en la marca de las 100 personas: entre $800 y $2,500 al mes. El costo real es la gente: un analytics engineer senior (una contratación de más de $120K en el mercado de EE.UU.) o un equipo como el nuestro corriendo el stack medio tiempo. Y si la IA está en tu roadmap de 2026, este es el trabajo previo: los agentes construidos sobre datos inconsistentes automatizan la inconsistencia.

Este es el stack que construimos en nuestra práctica de Data, y es exactamente el conjunto de preguntas detrás de la dimensión de Data del DGTL Readiness Index. A las ocho semanas, la discusión de métricas del lunes se acaba, porque todos están leyendo la misma tabla.

Relacionado: Infraestructura de datos para B2B → · Revenue Operations para B2B → · La práctica de Data →