Cómo controlar los costos de BigQuery y no llevarte sorpresas

El modelo de precios de BigQuery

BigQuery cobra por dos conceptos: almacenamiento (cuántos datos se guardan) y procesamiento (cuántos datos se leen al ejecutar consultas). Para análisis SEO, el procesamiento es el factor relevante.

La capa gratuita incluye:

• 1 TB de datos procesados al mes (consultas on-demand).
• 10 GB de almacenamiento activo al mes.
• 10 GB de almacenamiento de largo plazo al mes (datos no modificados en 90 días).

Un terabyte de procesamiento es generoso. Para ponerlo en contexto: una consulta típica de SEO que analiza 30 días de datos de GA4 de un sitio mediano procesa entre 1 y 15 GB. Con 1 TB de cuota, eso permite ejecutar entre 65 y 1.000 consultas al mes sin costo alguno.

Cómo saber cuánto consume una consulta

BigQuery muestra una estimación de bytes que procesará cada consulta antes de ejecutarla. En la esquina superior derecha del editor SQL aparece un texto como «This query will process 3.2 GB when run». Esa estimación permite decidir si vale la pena ejecutar la consulta o si conviene optimizarla primero.

Después de ejecutar, BigQuery muestra los bytes reales procesados en la barra de resultados. Conviene revisar este número periódicamente para detectar consultas ineficientes.

Práctica 1: siempre filtrar por fecha

La regla más importante. Las tablas de GA4 están particionadas por día. Sin filtro de fecha, BigQuery lee todas las tablas existentes:

-- MAL: escanea TODOS los datos históricos
SELECT COUNT(*) FROM `proyecto.analytics_123.events_*`

-- BIEN: escanea solo los últimos 30 días
SELECT COUNT(*)
FROM `proyecto.analytics_123.events_*`
WHERE _TABLE_SUFFIX BETWEEN
  FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY))
  AND FORMAT_DATE('%Y%m%d', CURRENT_DATE())

La diferencia puede ser de 50 GB vs 2 GB en un sitio con un año de datos. Olvidar el filtro _TABLE_SUFFIX es el error más costoso que se puede cometer.

Práctica 2: seleccionar solo las columnas necesarias

BigQuery es un almacén columnar: los costos se calculan por las columnas leídas, no por las filas. Seleccionar solo las columnas necesarias reduce significativamente el procesamiento:

-- MAL: lee TODAS las columnas (muchas son pesadas, como event_params)
SELECT * FROM tabla_eventos LIMIT 100

-- BIEN: lee solo las columnas que se necesitan
SELECT event_date, event_name, user_pseudo_id
FROM tabla_eventos LIMIT 100

La tabla de eventos de GA4 tiene columnas pesadas como event_params (array de registros anidados). Un SELECT * lee esa columna completa aunque no se use. Especificar columnas puede reducir el consumo a una décima parte.

Práctica 3: usar tablas con prefijo de fecha en GSC

Las tablas de GSC en BigQuery tienen el campo data_date como tipo DATE nativo. Filtrar por este campo es eficiente:

WHERE data_date BETWEEN
  DATE_SUB(CURRENT_DATE(), INTERVAL 28 DAY)
  AND CURRENT_DATE()

A diferencia de GA4, no se necesita _TABLE_SUFFIX porque las tablas de GSC no están particionadas por día en el nombre. Pero el filtro de fecha sigue siendo importante para limitar el volumen de datos procesados.

Práctica 4: previsualizar antes de ejecutar

BigQuery tiene un botón de vista previa (Preview) que muestra algunas filas de una tabla sin consumir cuota. Es útil para explorar la estructura de los datos antes de escribir la consulta. También se puede usar LIMIT 10 en una consulta simple para ver los datos con consumo mínimo.

Práctica 5: guardar resultados en tablas de destino

Si una consulta costosa se ejecuta frecuentemente, se puede guardar el resultado en una tabla de destino. Las consultas posteriores leen de esa tabla intermedia (que es mucho más pequeña) en lugar de reprocesar los datos brutos:

-- Crear una tabla con los resultados (se ejecuta una vez al día)
CREATE OR REPLACE TABLE `proyecto.mi_dataset.resumen_diario` AS
SELECT
  PARSE_DATE('%Y%m%d', event_date) AS fecha,
  COUNT(DISTINCT session_id) AS sesiones
FROM `proyecto.analytics_123.events_*`
WHERE _TABLE_SUFFIX = FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY))
GROUP BY fecha

Las Scheduled Queries de BigQuery permiten automatizar este proceso: una consulta se ejecuta cada mañana, actualiza la tabla de resumen, y todas las consultas del día leen de la tabla pequeña.

Práctica 6: configurar alertas de presupuesto

En Google Cloud Console, se pueden crear alertas de presupuesto que envían un email cuando el consumo se acerca a un umbral definido. Configurar una alerta al 50% y 90% del presupuesto mensual permite reaccionar antes de que se generen costos inesperados:

1. Ir a Billing > Budgets & alerts en la consola de Google Cloud.
2. Crear un presupuesto con el monto deseado (puede ser 0 USD si solo se quiere usar la capa gratuita).
3. Configurar alertas al 50%, 80% y 100% del presupuesto.

Cuánto cuesta fuera del free tier

Si se supera el terabyte gratuito, el precio estándar es de 6.25 USD por TB procesado (modelo on-demand). Para la mayoría de los profesionales de SEO, eso significa que incluso superando la capa gratuita, los costos mensuales rara vez pasan de unos pocos dólares.

Para equipos con uso intensivo, BigQuery ofrece el modelo de flat-rate pricing (capacidad reservada) que puede ser más económico, pero solo se justifica con volúmenes mucho mayores que los habituales en SEO.

Resumen de buenas prácticas

• Filtrar siempre por fecha (_TABLE_SUFFIX en GA4, data_date en GSC).
• Seleccionar columnas específicas, nunca SELECT * en producción.
• Revisar la estimación de bytes antes de ejecutar consultas grandes.
• Usar tablas de destino para consultas recurrentes.
• Configurar alertas de presupuesto en Google Cloud.

Con estas prácticas, la gran mayoría de los análisis SEO se mantienen dentro de la capa gratuita indefinidamente. El siguiente artículo cubre los errores más comunes al empezar con SQL para SEO y cómo evitarlos.