Ask a data engineer at a Singapore startup what they use for their analytics layer and the answer, more often than not, is BigQuery. Ask the same question at a mid-market eCommerce business. Ask at an agency managing analytics for multiple clients. Ask at an enterprise team that migrated off an on-premise data warehouse two years ago. The answer is BigQuery with a frequency that, five years ago, would have been surprising. Today it is simply the default.
Defaults happen for reasons. They are rarely accidents. BigQuery did not become the go-to analytics layer for Singapore data teams because of a single decisive feature or because of marketing spend. It became the default because a combination of technical architecture decisions, ecosystem alignment, pricing model, and timing converged in a way that made it the obvious answer to a problem — “where does our analytical data live?” — that every data-capable organisation eventually has to solve.
Understanding why BigQuery won this position matters for teams that are evaluating their options for the first time, and for teams that are already using BigQuery and want to understand what they have and where its limits apply. This article covers the technical and ecosystem reasons BigQuery became the default, what being the default actually means in practice, and where the boundaries of that position still sit. It draws on the perspective of Engine Analytics, a data analytics company in Singapore that has built BigQuery-based analytics environments across SaaS, eCommerce, healthcare, and enterprise clients.
Before BigQuery became the default, Singapore data teams with serious analytical requirements typically used one of three approaches. On-premise data warehouses — Oracle, SQL Server, or Teradata — handled large-enterprise environments but required dedicated infrastructure teams, significant upfront capital, and upgrade cycles that lagged years behind analytical requirements. Redshift, Amazon’s cloud data warehouse, was widely adopted through 2018 and 2019 and remains in active use, but requires cluster sizing decisions and ongoing management that adds operational overhead the fully-serverless BigQuery eliminates. And many teams simply used PostgreSQL or MySQL read replicas as their analytical layer — workable for modest data volumes but increasingly painful as data grew and analytical query complexity increased.
The migration stories are consistent in their structure. An event that outgrew what an on-premise warehouse could handle affordably. A Redshift cluster that needed to be resized and then resized again. A read replica that started affecting production performance as analytical query load increased. In each case, the push away from the existing solution converged with BigQuery’s growing ecosystem maturity and Singapore’s accelerating Google Cloud adoption — and BigQuery became the natural destination.
The timing of Google’s acquisition of Looker in 2019 and the subsequent development of what became the modern Google data stack also mattered. The combination of BigQuery as the data layer, dbt for transformation, Looker or Looker Studio for reporting, and GA4’s native BigQuery export created a coherent, well-integrated architecture that data teams could adopt as a system rather than assembling from competing parts. Singapore’s strong Google Ads and Analytics adoption meant that many teams were already partly inside the Google ecosystem, which reduced the activation energy required to move the analytics layer there as well.
Serverless architecture is BigQuery’s most significant operational advantage. There are no clusters to provision, no nodes to scale, no capacity planning decisions to make before running a query. BigQuery allocates compute dynamically against each query and releases it immediately after. For a data team that wants to focus on analytics rather than infrastructure management, this removes a category of ongoing operational work that Redshift and traditional data warehouses impose by design.
The separation of storage and compute is what makes BigQuery’s pricing model work at scale. Storage is cheap and persistent. Compute is charged per query against the on-demand model, or reserved at fixed cost through slot commitments for teams with predictable, high-volume query workloads. For organisations with variable analytical load — heavy queries during business hours, minimal usage overnight — on-demand pricing is significantly more cost-efficient than a Redshift cluster running at constant cost regardless of utilisation.
Native support for nested and repeated fields allows event data to be stored in BigQuery in its natural JSON structure rather than being flattened into normalised relational tables. For SaaS and eCommerce businesses generating high-volume clickstream or product event data, this is a meaningful technical advantage: the event schema can evolve without requiring table restructuring, and queries can target specific nested fields without scanning the entire event record. Combined with partition pruning and clustering, this makes BigQuery exceptionally efficient for the analytical query patterns that growth-stage businesses actually run. The data engineering principles behind this architecture are covered in more depth in the article on what data engineering means for business leaders.
Individual technical features explain why BigQuery was adopted. The ecosystem explains why it stayed the default. The GA4 native export, which lands raw and unsampled event data directly into BigQuery at no additional cost, created an immediate, compelling use case for every business already running GA4. The alternative — using the GA4 API directly with its sampling limitations and rate constraints — produces inferior data at inferior cost for any property beyond modest scale. For Singapore businesses investing in analytics on top of GA4, BigQuery became not just a good option but the obviously correct infrastructure choice.
The dbt ecosystem grew in parallel with BigQuery adoption and made the transformation layer significantly more manageable. dbt’s BigQuery adapter is mature and well-maintained, its jinja-based templating handles BigQuery’s partitioned table syntax cleanly, and the dbt Cloud managed service integrates with BigQuery’s permissions model without significant friction. For teams building analytical data models — the clean, business-logic-bearing tables that dashboards and analysts read from — dbt on BigQuery is the combination that most Singapore data teams converge on. The reporting layer built on top, covered in the piece on data-driven decision-making with business intelligence, connects directly to the BigQuery output of these models.
The connector ecosystem that lands non-Google source data into BigQuery — through Fivetran, Airbyte, or custom pipelines — has also matured significantly. Salesforce, HubSpot, Shopify, Meta Ads, Stripe, Zendesk, and most other platforms used by Singapore businesses have maintained BigQuery connectors with predictable, documented schemas. The practical friction of getting data from a SaaS platform into BigQuery is now low enough that it is rarely a reason to choose a different analytical layer.
“Default” does not mean universally correct. BigQuery is the right analytical layer for most Singapore data teams working at meaningful scale with diverse data sources. It is not necessarily the right choice for every use case. Organisations with extremely high query concurrency requirements and predictable workloads may find Redshift’s slot-based reservation model more cost-predictable at scale. Businesses deeply embedded in the Azure or AWS ecosystems may have better reasons to use Synapse or Redshift than to introduce a GCP dependency. And for very small teams with simple analytical needs, the operational overhead of a cloud data warehouse — any cloud data warehouse — may not be justified at all.
BigQuery is also not a substitute for the data engineering work that makes an analytical layer useful. A BigQuery project full of raw, unmodelled tables is not meaningfully more valuable than the source systems the data came from. The value emerges from the transformation layer, the data models, the quality monitoring, and the reporting infrastructure built on top — the full stack that turns raw data movement into analytical capability. The piece on real-time analytics covers one dimension of that full stack for teams whose use cases require data freshness that batch pipelines cannot provide.
The teams that get the most value from BigQuery are the ones that treat it as an analytical layer with clear architectural boundaries — not as a general-purpose database or a replacement for operational systems. Raw source data lands in BigQuery from pipelines. Transformation logic runs in a separate layer and produces clean, business-logic-bearing tables. Reporting tools read from those tables, not from raw data. Access controls are applied at the dataset and table level, not just at the BI tool level. Query cost monitoring is in place before the team grows beyond two or three analysts.
Dataset and table naming conventions, partition strategies, and documentation standards established early pay compounding dividends as the analytical environment grows. A BigQuery project that has been organised thoughtfully from the start is navigable and maintainable by any competent data engineer. One that has grown organically without structure becomes a source of confusion and technical debt that slows down every subsequent analytical project.
Whether you are adopting BigQuery for the first time or working to restructure an existing environment that has outgrown its initial organisation, the decisions that matter most are architectural — dataset structure, partitioning strategy, transformation layer design, access control, and cost governance. View our data and AI services, explore our engagement plans, or get in touch and we can review your current setup and map out what a well-architected BigQuery analytics layer looks like for your specific team and data sources.
Engine Analytics is a data analytics company in Singapore that designs and builds BigQuery analytics environments — from initial architecture through transformation models, quality monitoring, and the reporting layer that stakeholders across the business rely on.
For teams with three or more meaningful data sources and growing analytical requirements, yes. The serverless model means there is no cluster to manage and no infrastructure cost when the environment is idle. The free tier is generous enough to evaluate the platform properly. The main consideration is establishing query cost controls before opening access broadly — unmanaged query costs are the most common early mistake.
BigQuery wins on operational simplicity — no cluster sizing, no ongoing maintenance — and on Google ecosystem integration, particularly GA4 and Google Ads. Redshift has a cost advantage for very high, very predictable concurrency workloads where slot reservations make sense. For most Singapore businesses that are not running extremely consistent, high-volume analytical workloads, BigQuery’s on-demand model is more cost-efficient and significantly easier to operate.
— Engine Analytics | Singapore’s data and AI consultancy — building BigQuery analytics environments that are well-architected from the start and built to scale with your team’s evolving analytical requirements.
