Skip to main content

Data pipeline optimisation with Google Cloud and Dataform

Prasanna Venkatesan22 April 20253 min read
Data pipeline optimisation with Google Cloud and Dataform

In our recent engagement with a client, we went on a journey to transform their data pipelines, tackling inefficiencies in performance and cost within their Google Cloud BigQuery environment. Our efforts culminated in a comprehensive optimisation strategy that used Dataform, improved SQL practices, and implemented tailored solutions for significant performance gains and cost savings. Here’s a deep dive into the highlights of our project.

Identifying inefficiencies in BigQuery workflows

We began by analysing the existing data architecture, identifying key areas of inefficiency:

  1. Long view chains: Multiple layers of views increased complexity and degraded performance.
  2. Lack of incremental logic: Transformations processed entire datasets unnecessarily, increasing costs.
  3. Unoptimised tables: Absence of partitioning and clustering led to full table scans.

Transitioning to Dataform

To address these challenges, we transitioned from BigQuery Scheduled Queries to Dataform, unlocking the following benefits:

  • Improved maintainability: Modular SQL scripts made workflows easier to debug and maintain.
  • Version control: Seamless integration with Git allowed better collaboration and change tracking.
  • Automated dependency management: Dependencies were automatically managed, minimising manual intervention and errors.
  • Incremental processing capabilities: Focused data processing only on updated data, enhancing efficiency.
  • Assertions for data quality: Automated checks ensured consistency and reliability throughout the pipeline.
30-minute consultation


Book your free Dataform consultation

Infrastructure audit Transformation plan Efficiency analysis

Key optimisation strategies

  • Query structure improvements: Refactored subqueries into Common Table Expressions (CTEs), improving readability and debugging efficiency.
  • Consolidation of intermediate tables: Combined redundant views into fewer tables, reducing complexity and redundant operations.
  • Implementation of incremental tables: Processed only new or updated data, significantly reducing data scanned and associated costs.
  • Partitioning of tables: Partitioned tables based on relevant date fields, improving query performance.
  • Eliminating full table scans: Restructured incremental tables to prevent full table scans, ensuring more targeted data processing.

Cost savings analysis

Our optimisation efforts translated into substantial cost savings:

  1. Data processed for key tables:
    • BigQuery costs were reduced by over 40% annually due to a 92% reduction in data processed for some large output tables.
  2. Dashboard optimisation:
    • Dashboard redesigns also contributed to query optimisation. By separating lightweight and heavy charts onto different pages and consolidating scorecards, redundant queries and unnecessary filters were eliminated. This resulted in a substantial reduction -  hundreds of GBs per dashboard load -  from the final output tables.
  3. Operational efficiencies:
    • Reduced manual dependency management, debugging, and new model setup, saving approximately 32 engineer hours monthly, saving close to 20% in cost per month.

Conclusion

This project demonstrates how targeted optimisations can transform data pipelines, improving performance while dramatically reducing costs. Leveraging tools like Dataform and best practices in SQL and BigQuery, we delivered a smarter, more efficient solution tailored to the client’s needs.

Resources

Need help with your data platform?

We build intelligence platforms on BigQuery, Dataform and Google Cloud - from setup to ongoing optimisation.

How ready is your data?

Take our short assessment to find out where your data stack stands and what to prioritise next.


Suggested content

BigQuery Tips: When your query is technically correct but BigQuery won't run it

There is a particular kind of frustration that comes from staring at a query you know is correct and watching it fail. No syntax error. No logic problem. Just a wall. We hit two of them on the same project. What we were building The job was to migrate ga4_daily_snapshot for a large enterprise client from a BigQuery scheduled query into a proper Dataform pipeline. The scheduled query had been added to over time until it was too large to maintain with any confidence. Moving it to Dataform w

Katie Kaczmarek17 Aug 2026

BigQuery Tips: The subquery in your WHERE clause that's scanning your entire table

There is a pattern that appears in a lot of BigQuery pipelines and looks completely reasonable. You have a control table that stores the latest processed date. Rather than hardcoding a date into your query, you pull it dynamically: SELECT * FROM `project.dataset.events` WHERE event_date = ( SELECT latest FROM `project.dataset.control_table` ); The query returns the right results. The logic is clean. And if your events table is large and date-partitioned, you might be scanning the entire

Katie Kaczmarek13 Aug 2026

BigQuery Tips: Arrays in BigQuery - what they are and how to get data out of them

If you have ever opened a GA4 export in BigQuery for the first time and found yourself looking at a column called event_params that seemed to contain an entire table inside each row, this post is for you. Arrays are not trying to make your life harder. Once you understand why they exist and what to do with them, they stop being intimidating. Why BigQuery uses arrays GA4 tracks events. Each event can have many parameters. A purchase event might have a transaction ID, a value, a currency an

Katie Kaczmarek10 Aug 2026