{"id":8663,"date":"2026-09-17T06:51:17","date_gmt":"2026-09-17T06:51:17","guid":{"rendered":"https:\/\/prwatech.in\/blog\/?p=8663"},"modified":"2026-09-18T17:29:50","modified_gmt":"2026-09-18T17:29:50","slug":"executing-queries-of-multiple-gb-of-data-in-seconds","status":"publish","type":"post","link":"https:\/\/prwatech.in\/blog\/google-cloud-platform\/bigquery\/executing-queries-of-multiple-gb-of-data-in-seconds\/","title":{"rendered":"BigQuery Speed: Querying Terabytes of Data in Seconds"},"content":{"rendered":"\r\n

Analyzing Massive Datasets With BigQuery<\/h1>\r\n

BigQuery is built to scan enormous amounts of data quickly, and the clearest way to see that is to run a few queries against a genuinely huge public dataset and watch how little time it actually takes. This uses a public benchmark dataset of Wikipedia page view data to show that directly.<\/p>\r\n

\r\n
\r\n
\r\n
\r\n
\r\n
\r\n
\r\n
\r\n
\r\n
\r\n
\r\n
\r\n

In the era of burgeoning digital information, the ability to efficiently process and derive insights from vast datasets is paramount. Enter BigQuery, Google’s fully managed, serverless data warehouse solution designed to tackle the challenges of analyzing massive datasets with unprecedented speed and scalability.<\/p>\r\n

In this article, we will explore the foundational principles and capabilities of BigQuery, empowering organizations to unlock the full potential of their data assets. From its seamless integration with Google Cloud Platform<\/a> to its SQL-like querying capabilities and real-time data analytics features.<\/p>\r\n

Step by Step Process of Analyzing Datasets with BigQuery<\/h2>\r\n<\/div>\r\n<\/div>\r\n<\/div>\r\n<\/div>\r\n<\/div>\r\n<\/div>\r\n<\/div>\r\n<\/div>\r\n<\/div>\r\n
\r\n

Step One: Open BigQuery<\/h3>\r\n

Open the console, then the\u00a0 Open Menu > Big Query <\/a>> SQL Workspace.<\/p>\r\n<\/div>\r\n<\/div>\r\n<\/div>\r\n<\/div>\r\n

 <\/p>\r\n\r\n\r\n\r\n

\"\"<\/figure>\r\n\r\n\r\n\r\n

Query One: A Full Table Scan<\/h3>\r\n

SELECT
\u00a0\u00a0*
FROM
\u00a0\u00a0`bigquery-samples.wikipedia_benchmark.Wiki10B`
LIMIT
\u00a0\u00a05<\/p>\r\n

Click Run. This query processes 692 GB and returns in under a second. It is fast because a LIMIT clause does not reduce how much data BigQuery has to scan to answer a SELECT star query, but the dataset itself is not being filtered or aggregated at all, just returned as is.<\/p>\r\n\r\n\r\n\r\n

\"\"<\/figure>\r\n\r\n\r\n\r\n

Query Two: Filtering and Grouping<\/h3>\r\n

SELECT
\u00a0\u00a0language,
\u00a0\u00a0title,
\u00a0\u00a0SUM(views) AS views
FROM
\u00a0\u00a0`bigquery-samples.wikipedia_benchmark.Wiki10B`
WHERE
\u00a0\u00a0title LIKE “%Google%”
GROUP BY
\u00a0\u00a0language,
\u00a0\u00a0title
ORDER BY
\u00a0\u00a0views DESC;<\/p>\r\n

Click Run. This one processes 425 GB and finishes in 8.3 seconds, filtering down to Wikipedia titles containing Google, then totalling views by language and title.<\/p>\r\n\r\n\r\n\r\n

\"\"<\/figure>\r\n\r\n\r\n\r\n

Query Three: A Much Larger Table<\/h3>\r\n

This is the same query as above, run against Wiki100B, a table roughly ten times the size:<\/p>\r\n

SELECT
\u00a0\u00a0language,
\u00a0\u00a0title,
\u00a0\u00a0SUM(views) AS views
FROM
\u00a0\u00a0`bigquery-samples.wikipedia_benchmark.Wiki100B`
WHERE
\u00a0\u00a0title LIKE “%Google%”
GROUP BY
\u00a0\u00a0language,
\u00a0\u00a0title
ORDER BY
\u00a0\u00a0views DESC;<\/p>\r\n

Click Run. This processes 4.1 TB and finishes in around 47.5 seconds, roughly ten times the data in less than six times the time.<\/p>\r\n\r\n\r\n\r\n

\"\"<\/figure>\r\n

If bigquery-samples ever stops resolving in your own project, bigquery-public-data is the current primary namespace Google uses for its public datasets, and is worth checking as the modern equivalent.<\/p>\r\n

Why This Is Actually Fast<\/h2>\r\n

Two things make this possible. BigQuery stores data in a columnar format, so a query only has to read the specific columns it references, not every column in every row, which is a big part of why query two processes less data than query one despite querying the same table. On top of that, BigQuery spreads a query across a large number of machines running in parallel, so scanning 692 GB does not mean waiting for one machine to read through it sequentially, it means thousands of machines each reading a small slice of it at the same time.<\/p>\r\n

Why Selecting Specific Columns Matters for Cost<\/h2>\r\n

Query one uses SELECT star, which reads every column in the table, and its 692 GB reflects that. Queries two and three only reference language, title, and views, and process less data as a result, even though they run against the same size or larger table. Since BigQuery bills by the amount of data a query actually processes, this is not just a performance detail, it directly affects cost. Selecting only the columns a query genuinely needs, instead of defaulting to SELECT star, is one of the simplest ways to keep both query time and cost down.<\/p>\r\n

Common Mistakes to Avoid<\/h2>\r\n