Armar un data lake con BigQuery para una pyme mexicana es totalmente viable en 2026, pero la pregunta correcta no es "cómo armar BigQuery", es "qué problema operativo voy a resolver con datos unificados". Sin esa claridad, BigQuery se convierte en un proyecto técnico carísimo que nadie usa. Cuando los datos se unifican, los problemas se anuncian solos.
Esta guía cubre arquitectura honesta, costos reales en pesos mexicanos, qué cargar primero, errores comunes y cuándo BigQuery deja de ser la opción correcta a favor de algo más simple.
La arquitectura mínima que funciona
Para una pyme mexicana entre 20 y 200 empleados, la arquitectura de data lake con BigQuery se estructura en cuatro capas conectadas en serie:
| Capa | Función | Tecnología |
|---|---|---|
| Ingesta | Extrae datos de fuentes hacia GCS o BQ raw | Python workers, Fivetran, Airbyte |
| Bronze | Almacena datos crudos sin transformar | BigQuery dataset bronze, particionado por fecha |
| Silver | Normaliza tipos, nombres, duplicados | dbt models, view materializadas |
| Gold | Modelos de negocio listos para BI | dbt + tablas materializadas refrescadas diario |
Encima de Gold conectas Looker Studio, Metabase o cualquier BI moderno. Debajo de Bronze, GCS guarda archivos crudos en formato parquet para auditoría y reproceso eventual.
Por qué BigQuery encaja con pymes mexicanas (cuando encaja)
BigQuery tiene dos ventajas reales para pyme en México. La primera es el modelo de costo: pagas almacenamiento barato y procesamiento por query, sin servidores corriendo 24 por 7. Una pyme que consulta su dashboard 100 veces al día paga 600 a 1,500 MXN al mes en infraestructura, contra 8 mil o más en un servidor dedicado.
La segunda ventaja es la escala invisible. Si tu pyme crece 5x en clientes y datos, BigQuery escala solo sin que cambies infraestructura. Postgres y Supabase requieren upgrades de instancia conforme creces.
Cuando BigQuery deja de tener sentido: si tu pyme genera menos de 20 mil filas al día y tu volumen activo no pasa de 5 GB, Postgres en Supabase Pro a 500 pesos mensuales hace lo mismo más barato y con menos complejidad operativa.
El caso real: distribuidora de servicios, 197 tablas, 12 semanas
Una distribuidora con 10 años de operación llegó con datos en SQL Server 2019 desordenados, 13 millones de filas legacy y reportes mensuales que mentían. No usamos BigQuery puro al final, usamos arquitectura Bronze, Silver, Gold sobre Supabase con GCS para almacenamiento bruto. Los números entregados:
- 3.6M filas migradas en 48 horas con chunking paralelo por rango de PK
- 1.17 TB en GCS como bronze parquet raw, costo mensual menos de 500 MXN
- 197 tablas snapshot, 825 vistas Silver, 75 tablas Gold materializadas
- Verificación fila por fila entre fuente, bronce, plata y oro
- 57 políticas RLS y 17 roles RBAC para multi-tenant
- Lo que un partner tradicional cotizó en 18 meses entregamos en 12 semanas
Para esa empresa, BigQuery hubiera funcionado pero hubiera costado 4 a 6 veces más al mes con queries mal optimizadas. La decisión de stack siempre la dicta el patrón de consulta, no la moda.
Qué cargas primero al data lake
El orden importa porque cargar todo a la vez es la receta para abandonar el proyecto en la semana 8. Para una pyme mexicana típica, este es el orden que entrega valor más rápido:
Semana 1 y 2: ERP o sistema contable. Catálogo de cuentas, facturas emitidas, facturas recibidas, asientos contables. Esto desbloquea reportes financieros confiables.
Semana 3 y 4: CRM o registro de clientes. Clientes, contactos, deals, etapas de venta. Esto desbloquea seguimiento comercial sin Excel paralelo.
Semana 5 y 6: POS o ecommerce. Ventas detalladas, productos, precios, descuentos. Esto desbloquea análisis de margen real producto por producto.
Semana 7 y 8: Bancos y tesorería. Movimientos bancarios diarios, conciliados contra ERP. Esto desbloquea visibilidad de caja en tiempo real.
Semana 9 y 10: Datos no estructurados. PDFs de proveedores, archivos de operación, correos críticos. Pasan por OCR si aplica y se vuelven indexables.
Semana 11 y 12: Dashboards por rol. CEO ve métricas estratégicas, director ve operación, equipo ve sus tareas.
Costos reales en pesos mexicanos para BigQuery
Para una pyme con 200 GB activos en Bronze, 50 GB en Silver, 10 GB en Gold y queries moderadas, el costo mensual real de BigQuery se descompone así:
- Almacenamiento 260 GB activo: 110 MXN al mes
- Almacenamiento 1 TB en GCS bronze parquet raw: 450 MXN al mes
- Procesamiento queries dashboard, 500 GB consultados al mes: 65 MXN
- Procesamiento queries ad-hoc analista, 2 TB al mes: 260 MXN
- Procesamiento jobs dbt refresh diario, 3 TB al mes: 390 MXN
- Total mensual infraestructura: alrededor de 1,275 MXN
Súmale licencia de Fivetran o Airbyte si los usas (entre 1,500 y 8,000 MXN al mes según volumen), o cero si usas workers Python propios.
Errores que cuestan meses
Cargar Bronze con transformaciones encima. Bronze tiene que ser raw exacto, sin tocar. Si "limpias" en ingesta, no puedes auditar contra la fuente cuando aparezca una discrepancia.
Queries sin LIMIT ni partición. Un SELECT sin filtro contra una tabla particionada de 1 TB cuesta 5 USD por ejecución. Multiplica por 100 al día y son 500 USD diarios en queries fantasma.
dbt sin tests. Cada modelo Gold tiene que tener al menos un test de integridad: no nulos, único, rangos esperados. Sin tests, tu dashboard miente con confianza y el CEO toma decisiones con datos rotos.
Materializadas que se refrescan a cada query. Si una tabla Gold tarda 8 minutos en construirse, refréscala 1 vez al día, no 1 vez por consulta del dashboard. Cada refresh innecesario cuesta dinero.
Mezclar OLTP y OLAP en BigQuery. BigQuery está hecho para analítica, no para escrituras transaccionales constantes. Si tu aplicación necesita insertar 1,000 registros por minuto, no es ahí donde van.
BigQuery contra alternativas para pyme
Para una pyme mexicana de 50 empleados con datos crecientes pero menos de 50 millones de filas activas, Supabase Pro con arquitectura Bronze, Silver, Gold sobre Postgres entrega lo mismo más barato (alrededor de 500 MXN al mes) y con RLS nativo para multi-tenant. La decisión por BigQuery se justifica cuando proyectas pasar 100 millones de filas en 12 meses, cuando ya tienes Google Workspace como ecosistema o cuando consultas analíticas pesadas exceden lo que Postgres maneja sin servidores grandes.
Próximos pasos
Antes de abrir cuenta de BigQuery, ejecuta un mapeo de 2 semanas de tus 5 sistemas más importantes y mide volumen real de filas, frecuencia de consulta y latencia aceptable. Esa medición decide si BigQuery, Supabase o algo más simple resuelve tu caso.
En MAGIA Core entregamos data lake unificado en 12 semanas con stack abierto. Sin retainers, sin licencias atadas, código y datos a tu nombre desde el día uno.