Imagina una distribuidora de 12 personas que pasó su reportería de ventas a BigQuery hace dos años. Los pedidos llegan cada noche desde el ERP, un tablero de Looker Studio muestra la venta del día anterior por cliente, y el dueño lo abre con el primer café. Durante mucho tiempo la factura fue tan chica que nadie la miró. Hasta que un mes dejó de serlo, y lo incómodo es que no había cambiado nada. Ninguna tabla nueva, ningún reporte nuevo, nadie escribió una consulta ingeniosa. Los datos simplemente crecieron, y un tablero que ahora abren ocho personas cada mañana siguió haciendo exactamente lo mismo de siempre.
Esta es la factura de Google Cloud que más nos piden explicar, y casi siempre se arregla en una tarde. El arreglo no es rehacer nada. Es saber cuál de los dos medidores está corriendo, ponerle un techo, y lograr que una tabla deje de leerse completa. Este es el orden en que lo trabajamos en un proyecto de cliente. Los precios y el comportamiento que siguen salen de la documentación de Google, revisada el 6 de octubre de 2026.
Una factura de BigQuery tiene dos medidores, y solo uno se mueve rápido
El almacenamiento es el medidor lento. El cómputo es el rápido, y en el modelo on-demand, que es el que viene por defecto, pagas por los bytes que lee cada consulta, no por cuánto tarda ni por lo bien escrita que esté.
En on-demand, el primer 1 TiB de datos procesados por consultas al mes es gratis, y por encima de eso el precio de lista es de USD 6.25 por TiB (página de precios de BigQuery, revisada el 6 de octubre de 2026). La página muestra la tarifa de la ubicación que elijas, así que confirma la tuya antes de hacer cualquier cuenta.
El almacenamiento se cobra por gibibyte-hora, con los primeros 10 GiB al mes gratis. El ejemplo de la propia página de precios deja 1 TiB de almacenamiento lógico activo guardado un mes completo en us-central1 en USD 23.552 (revisado el 6 de octubre de 2026). Hay un segundo descuento que casi ningún equipo chico nota: una tabla o partición que no se modifica durante 90 días seguidos pasa a almacenamiento de largo plazo y la tarifa baja cerca de la mitad. Consultarla, exportarla, copiarla o crear una vista encima no reinicia ese reloj de 90 días. Solo modificar los datos lo reinicia.
Pon esos dos números uno al lado del otro y la forma de una factura chica de analítica queda clara. Un terabyte quieto un mes cuesta más o menos lo que cuesta leer cuatro terabytes una vez. Cuando la factura salta en una empresa de quince o veinte personas, casi siempre es cómputo, y casi siempre es una consulta que se repite.
Qué revisamos primero en el proyecto de un cliente
Tres cosas, en este orden, antes de tocar una sola tabla.
De qué está hecha la factura. En los reportes de Cloud Billing, filtra por el proyecto y agrupa por SKU. El análisis de BigQuery y el almacenamiento de BigQuery son líneas distintas. Si el análisis aplasta al almacenamiento, el problema es una consulta. Si el almacenamiento aplasta al análisis, el problema es que alguien guarda diez años de exportaciones crudas que nunca abrió.
Qué consultas leen más bytes. BigQuery registra cada job en INFORMATION_SCHEMA, y consultar esa vista no cuesta. Cambia la región por la tuya:
SELECT
user_email,
COUNT(*) AS jobs,
SUM(total_bytes_billed) / POW(1024, 4) AS tib_billed
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
AND job_type = 'QUERY'
AND state = 'DONE'
GROUP BY user_email
ORDER BY tib_billed DESCQuién las está corriendo. La columna user_email es todo el diagnóstico. Si arriba de esa lista aparece el correo de una persona, alguien está explorando datos a mano y se le enseña en diez minutos. Si arriba aparece una cuenta de servicio, el que lo hace es un tablero o una consulta programada, sin que nadie mire, y ese es el caso caro: nunca se aburre ni se detiene.
On-demand o Editions: cómo lo decidimos en una pyme
BigQuery tiene dos formas de cobrar el cómputo. On-demand cobra los bytes que leen tus consultas. Editions te vende capacidad de procesamiento medida en slots, con una base que mantienes siempre y un máximo al que puede llegar el autoescalado, cobrada por slot-hora, en los niveles Standard, Enterprise y Enterprise Plus. Las tarifas están en esa misma página de precios; revísalas para tu región en vez de confiar en una cifra de un blog, porque cambian por nivel y por compromiso.
Para casi todas las pymes con las que trabajamos gana on-demand, y la decisión ni siquiera es reñida. Editions vale la pena con carga sostenida y concurrente, de esa que mantiene la capacidad ocupada durante horas. Una carga nocturna y un tablero que ocho personas abren en la mañana no es eso. Y hay un detalle que pesa más de lo que parece: las cuotas personalizadas de consultas que describimos abajo aplican solo al modelo on-demand, así que pasarse a Editions para controlar costos te quita el freno duro en el que estabas confiando.
El tablero que lee la tabla completa cada mañana
Esta es la causa más común de una factura inesperada de BigQuery en una empresa que no se dedica a los datos. Vale la pena entender el mecanismo porque la solución toma minutos.
Un reporte de Looker Studio no es una consulta. Cada gráfico lanza la suya, y todo gráfico que no se responde desde la caché vuelve a BigQuery. Si el reporte apunta directo a una tabla cruda y los gráficos no traen un filtro de fecha que BigQuery pueda aprovechar, cada refresco lee la tabla entera. Ocho personas abriendo ese reporte antes de las nueve, sobre una tabla que crece cada noche, es una factura que sube sola.
Tres cambios, en el orden en que los hacemos:
- Alarga la frescura de datos. Looker Studio guarda resultados en memoria y responde las consultas repetidas desde ahí dentro de la ventana de frescura, lo que acelera el reporte y evita el cobro de BigQuery. El valor por defecto para una fuente de datos de BigQuery es de 12 horas. Si los datos solo llegan de madrugada, una ventana larga no le quita nada al lector y ahorra la mayoría de las consultas.
- Usa una sola fuente de datos reutilizable con credenciales del propietario. Los reportes armados con fuentes incrustadas, cada una con credenciales del visualizador, multiplican los refrescos. Una fuente compartida significa un solo juego de refrescos para todos.
- Apunta el reporte a un resumen, no a la tabla cruda. Una consulta programada que consolide los pedidos del día anterior en una tabla agregada chica, o una vista materializada que el tablero lea en lugar de la tabla, convierte un escaneo completo en algo trivial. Casi siempre este es el cambio que mueve la factura, y es una hora de trabajo.
Particiona y agrupa una vez, paga menos todos los días
Una tabla particionada se divide en segmentos, por lo general por fecha. Cuando una consulta filtra por la columna de partición, BigQuery lee solo los segmentos que necesita. El clustering, además, ordena las filas dentro de cada partición por hasta cuatro columnas, de modo que los filtros sobre esas columnas también saltan bloques. En una tabla con dos años de pedidos, la diferencia entre una lectura filtrada y un escaneo completo no es de un pequeño porcentaje.
Lo que casi nadie activa es la opción que hace que el cambio se sostenga:
CREATE TABLE analytics.pedidos (
pedido_id STRING,
cliente_id STRING,
pedido_ts TIMESTAMP,
total NUMERIC
)
PARTITION BY DATE(pedido_ts)
CLUSTER BY cliente_id
OPTIONS (
require_partition_filter = TRUE
);Con require_partition_filter activo, una consulta que no filtre por la columna de partición se rechaza antes de leer datos, y no te la cobran. Sobre una tabla que ya existe:
ALTER TABLE analytics.pedidos
SET OPTIONS (require_partition_filter = TRUE);Con eso, el escaneo completo accidental pasa a ser un error que alguien tiene que arreglar en vez de una línea en la factura. Avisa al equipo antes: los reportes y scripts que dependían del escaneo completo se van a romper esa misma mañana. De eso se trata, pero no debería sorprender a nadie.
Ya que estás ahí: SELECT * es la forma más cara de preguntar cualquier cosa, porque escanea todas las columnas, incluidas las que nadie lee. Nombrar las columnas que necesitas suele ser el segundo ahorro más grande después de particionar.
Dos techos que dejamos puestos antes de entregar
Máximo de bytes facturados, en las consultas que importan. BigQuery estima los bytes que va a leer una consulta antes de ejecutarla, y si la estimación supera el límite la consulta falla sin cobro. La propia guía de Google recomienda empezar bajo y subirlo según haga falta. Desde la línea de comandos:
bq query --use_legacy_sql=false --maximum_bytes_billed=2000000000 \
'SELECT pedido_id, total FROM analytics.pedidos WHERE DATE(pedido_ts) = CURRENT_DATE()'Una cuota diaria en el proyecto. En la consola de Cloud, en IAM y administración, Cuotas y límites del sistema, filtra el servicio por la API de BigQuery. Importan dos entradas: uso de consultas por día, que limita a todos los del proyecto en conjunto y viene en 200 TiB, y uso de consultas por día por usuario, que se aplica por separado a cada usuario y cuenta de servicio y viene sin límite. Las cuotas diarias se reinician a medianoche hora del Pacífico. Pon el techo del proyecto en un número que el trabajo honesto nunca alcance, que en una pyme son unos pocos TiB al día.
Las alertas de presupuesto te avisan. No te detienen
Casi toda pyme que auditamos tiene un presupuesto en Cloud Billing, y la mayoría de los dueños cree que es un tope. No lo es. Un presupuesto de solo alertas no limita el uso ni el gasto: manda correo a los destinatarios que elijas cuando el costo real o el proyectado cruza los umbrales que definiste. El gasto sigue corriendo.
Un tope de verdad sí existe, pero todavía no para BigQuery. Los presupuestos con tope de gasto, que pausan el uso de un servicio cuando el costo pasa el 100 por ciento del presupuesto, están disponibles en Preview desde el 27 de julio de 2026 para un conjunto limitado de servicios, entre ellos la API de Gemini, Gemini Enterprise Agent Platform, Cloud Run y las funciones de Cloud Run. BigQuery no está en esa lista al 6 de octubre de 2026, y de todas formas no montaríamos el control de costos de un cliente sobre una función en Preview. Para BigQuery el freno es la cuota personalizada de arriba. El presupuesto es el detector de humo.
Pon los dos. Dirige la alerta de presupuesto a una dirección de grupo y no al buzón de una sola persona, y agrega un umbral sobre el gasto proyectado además del gasto real, para que el aviso llegue cuando todavía se puede cambiar el mes.
Qué vigilamos el primer mes
Corre la consulta de INFORMATION_SCHEMA de arriba una vez por semana el primer mes y léela como tendencia. Tres señales te dicen que el arreglo aguantó: los bytes facturados por día se aplanan en vez de subir, las cuentas de servicio que encabezaban la lista caen por debajo de las personas, y no aparece ninguna consulta programada nueva que nadie recuerde haber creado. Revisa una vez que las tablas que esperas tener quietas de verdad pasaron a almacenamiento de largo plazo. Si alguna no pasó, algo la sigue tocando cada noche.
Cómo ayuda Guanacos Tech
La mayoría de las facturas de BigQuery que nos piden revisar no son un problema de diseño. Son cuatro ajustes de los que nadie avisó, en un proyecto que se armó para responder una pregunta y después se dejó solo. Leemos la exportación de facturación y el historial de jobs, encontramos la consulta que hace el daño, particionamos y resumimos la tabla que lee, y dejamos los techos puestos para que la próxima sorpresa sea una consulta rechazada y no una factura. Si eso se parece a tu proyecto, nuestra consultoría de Google Cloud empieza con una llamada de 30 minutos en la que vemos de qué está hecha tu factura.
Fuentes
- BigQuery pricing
- BigQuery: estimate and control costs
- BigQuery: create custom query quotas
- BigQuery: JOBS view (INFORMATION_SCHEMA)
- BigQuery: introduction to partitioned tables
- Cloud Billing: create, edit, or delete budgets and budget alerts
- Cloud Billing: manage spend cap budgets
- Looker Studio: manage data freshness