La reunión que se repite cada fin de año en empresa de tamaño medio: "vamos a cambiar de warehouse, ¿pero cuál?". Sale la consultoría con benchmark de query, el vendor con descuento, el deck con gráfico de TCO. En tres meses, la decisión normalmente se tomó — y en seis meses, la mitad de las empresas se arrepiente. No porque eligieron el equivocado, sino porque resolvieron el problema equivocado.
Snowflake, BigQuery y Databricks son, en 2026, funcionalmente equivalentes para el 80% de los casos de empresa de tamaño medio. Performance, costo promedio, recursos básicos — todos pasan. La elección real no está en la herramienta aislada; está en lo que rodea a cada una. Este texto es el criterio honesto que usamos antes de firmar un contrato de tres años.
Lo que nadie te dice en el pitch
Los tres vienen con la misma promesa: SQL escalable, separación compute/storage, gobernanza, performance previsible. Y entregan. Podés correr una operación de tamaño medio (5–50 TB, 20–100 usuarios técnicos) en cualquiera de los tres y tener un warehouse que funciona.
Las diferencias reales entre ellos existen — pero son marginales en ese alcance. Snowflake tiene la UX más pulida y la separación de compute más granular. BigQuery integra más fácil con el resto de Google Cloud (y cobra por query escaneada, no por compute reservado). Databricks tiene el mejor stack para ML/data science nativo y Delta Lake como formato abierto.
En tamaño medio, elegir entre Snowflake, BigQuery y Databricks es como elegir entre Toyota, Honda y Mazda: todos te llevan a donde necesitás. El criterio no es la marca, es lo que vive alrededor — taller, repuestos, hábito de mantenimiento.
Quien te llegue diciendo que uno de los tres es objetivamente mejor sin calificar por tu contexto está vendiendo, no comparando.
Cuatro criterios que deciden de verdad
Los criterios que importan separan empresas que eligen con claridad de las que quedan paralizadas.
- Stack que ya existe. Si la empresa ya es Google Cloud-first (GA4, Looker, Vertex AI), BigQuery reduce fricción de integración un 80%. Si es AWS-first, Snowflake suele ser el default. Si ya invirtió en Spark/MLflow, Databricks cierra el ciclo. Empresa "stack agnóstica" no existe — siempre hay peso de algún lado. Identificarlo antes de decidir.
- Perfil del equipo actual. Equipo fuerte en SQL y BI va a rendir más en Snowflake (UX optimizada para ese perfil). Equipo con background de ingeniería de datos y Python prospera en Databricks. Equipo que ya corre en GCP achata la curva en BigQuery. Intentar virar el perfil del equipo para encajar en la herramienta es el camino más caro de implementación.
- Roadmap de IA/ML real. Si el plan es solo reporte + dashboard, cualquiera de los tres sirve. Si el plan involucra entrenar modelos propios, feature store, MLOps serio — Databricks tiene 18 meses de ventaja en integración nativa. Si es solo correr LLM vía API con RAG sobre datos del warehouse, cualquiera sirve con plugins externos.
- Costo total honesto — no la tabla de precios. Los tres publican precios por crédito/hora/query. Ninguno de esos números refleja lo que tu empresa va a pagar de verdad. El número real depende del patrón de uso (picos vs. constante), madurez del equipo (queries optimizadas vs. queries sueltas), gobernanza (auto-suspend funcionando vs. cluster prendido domingo a la mañana). Empresa que no calcula costo histórico de uso antes firma contrato y descubre factura 2–3× mayor al tercer mes.
Quien responde los cuatro con claridad sabe cuál elegir. Quien responde "depende" en tres o más todavía no tiene caso de uso definido — y cualquier warehouse va a volverse proyecto eterno.
Dónde brilla cada uno de verdad (y dónde duele)
Sin esquivar el compromiso, tres frases honestas sobre cada uno:
Snowflake. Brilla en operación SQL pura con equipo de BI/analytics maduro. UX, separación de warehouses por workload, time travel son best-in-class. Duele en workloads de ML/data science nativo (necesita integraciones externas para tener lo que Databricks da en casa) y en federation de queries pesados.
BigQuery. Brilla en ecosistema Google (integración GA4, Vertex, Looker) y en modelo serverless real — no dimensionás cluster. Duele en previsibilidad de costo (modelo por query escaneada castiga queries mal escritas) y en UX menos pulida que Snowflake para equipo que viene de SQL clásico.
Databricks. Brilla en ML/data science nativo, soporte a Delta/Iceberg, pipelines streaming, notebooks colaborativos. Duele en complejidad — exige equipo más técnico, y operaciones puramente analíticas (BI + dashboard) pueden ser overkill. Curva de aprendizaje es la más empinada de los tres.
Ninguno de esos "duele" es deal-breaker si el resto de la ecuación encaja. Pero saber dónde duele antes de firmar es parte del trabajo de decisión.
La decisión que nadie quiere tomar — quedarse donde está
La pregunta menos hecha en la reunión de warehouse: ¿y si nos quedamos donde estamos?. La migración de warehouse cuesta entre 6 y 18 meses de equipo sénior, dependiendo del volumen y complejidad. Ese costo rara vez entra en el business case del "switch".
Vale calcular lo que de hecho cambia con la migración. Si la respuesta es "performance" y la empresa actual entrega queries en segundos, la ganancia es marginal. Si es "ML/IA", verificar si el cuello de botella real es el warehouse o el equipo. Si es "costo", normalmente es problema de gobernanza — va a aparecer en el warehouse nuevo también.
La empresa que decide cambiar sin entender esa cuenta migra dos veces en tres años.
Un movimiento honesto para 2026
Para una empresa de tamaño medio en decisión real sobre warehouse, tres movimientos prácticos antes de cualquier firma:
POC pago de 30 días con dato real. No la demo del vendor — POC interno, con 2–3 casos de uso tuyos, equipo tuyo, queries tuyas. Los tres vendors aceptan crédito promocional para eso. POC mide lo que el folleto no mide.
Cálculo de costo histórico simulado. Tomar uso real del último trimestre (volumen scaneado, número de queries, picos) y simular cada uno de los tres en el precio público. Las diferencias suelen ser de 30–50%, y rara vez el "más caro" del papel es el más caro en la práctica.
Conversación con 2 clientes de cada uno, del mismo tamaño que vos. El vendor te conecta. Si no conecta, pésima señal. Empresa de tamaño similar te dice en 30 minutos lo que el folleto esconde en 100 páginas.
Los tres warehouses son producto maduro de empresa seria. La peor decisión es firmar por el mejor pitch. La segunda peor es no decidir por seis meses por miedo a equivocarse. La mejor es entender que la sigla del warehouse importa menos que cómo la modelación está versionada arriba — y que el modelado dimensional bien hecho sigue valiendo en 2026, independiente de la elección de stack. (Para el ángulo complementario — no cuál es mejor, sino cuál es más caro abandonar — leer el examen de lock-in. Y para entender dónde encaja cada warehouse en el mapa de lo que sobrevivió del Modern Data Stack, la lectura complementa.) Antes de evaluar un cambio a lakehouse, vale confirmar si los criterios de adopción realmente aplican.