DuckDB in the cloud,
against decoded GA4 —
shared, scaled, persistent.
MotherDuck is DuckDB hosted, with the same query engine and the same Parquet-reading model, but with cloud workspaces, persistent secrets, and shared views your team can attach to. Point it at your Decode GA4 bucket and the whole analytics group queries one source — no warehouse to provision, no per-seat scan bills, no ETL.
DuckDB on a laptop is fine for one analyst. The moment two people need to query the same decoded GA4 dataset, you want shared credentials and shared views. That is what MotherDuck adds, without the warehouse cost.
The shape of the problem
Local DuckDB is excellent for individual exploration but it has no shared state. Each analyst registers their own HMAC secret, their own views, their own query history. When someone asks for the canonical session-level view of the last quarter, there is no canonical anything — just whatever happens to be open on whichever laptop. Multiply that by a five-person analytics team and it becomes a coordination problem disguised as a tooling problem.
Why a warehouse is the wrong answer
The instinct is to put the data in Snowflake or BigQuery and call it solved. But the workload is mostly read-heavy ad-hoc analysis on flat Parquet files that already exist. Paying warehouse pricing for that is the wrong shape of bill. You are paying for compute that is idle most of the day, and storage that duplicates what is already in GCS.
What MotherDuck adds on top of DuckDB
MotherDuck runs the same DuckDB engine in a cloud workspace. Secrets are registered once at the workspace level. Views created with CREATE VIEW persist for the team. Query history and saved queries are shared. The compute scales beyond local memory when a query needs it. Everything else — the SQL, the Parquet model, the schema — is identical to local DuckDB. You can move a query between the two with no rewrite.
The traditional approach
Everyone runs local DuckDB and emails the SQL
Each analyst sets up their own HMAC key, their own DuckDB install, their own copy of the canonical session view. When the schema changes or someone improves the view, the rest of the team finds out by Slack message. Five people end up with five subtly different definitions of "session".
Push everything into a warehouse
Stand up Snowflake or Redshift, copy the decoded GA4 data in, manage the warehouse cluster, manage the IAM, manage the bill. A workload that should be a SELECT against Parquet becomes a full warehouse operation, billed by the second of compute and the gigabyte of duplicate storage.
Run a shared dbt project just to materialise views
Build a dbt project whose only purpose is to give the team a shared definition of session and event tables. Now you have a transformation layer with no business modelling, scheduled refreshes you do not need, and a CI process for what could have been a CREATE VIEW.
Decode GA4 + MotherDuck vs the alternatives
| Feature | Decode GA4 + MotherDuck | Warehouse or local-only |
|---|---|---|
| Shared workspace and credentials | Yes — registered once at workspace level | Per-machine secrets, per-seat config |
| Compute model | Cloud DuckDB, scales beyond laptop RAM | Warehouse cluster you size and pay for |
| Storage cost for analytics | GCS Parquet only — no duplicate copy | Duplicate storage inside the warehouse |
| Shared views | CREATE VIEW persists for the team | dbt project or copy-paste SQL |
| Query portability with local DuckDB | Identical SQL, no rewrite | Warehouse dialect drift |
| Time to first shared query | Minutes after the secret is registered | Days of warehouse provisioning and IAM |
Decode writes Parquet to GCS. MotherDuck registers the bucket once, the team queries it forever.
- [ 1 ]
Create a MotherDuck workspace
Sign up for MotherDuck and create a workspace for the analytics team. Workspace membership controls who can attach, query, and create persistent views against the connected sources.
- [ 2 ]
Subscribe to Decode GA4 and deploy events_external
Decode GA4 is a Google Cloud Marketplace listing. Run the installer with the events_external template pointing at a GCS bucket — the same bucket your MotherDuck workspace will read from.
- [ 3 ]
Generate a GCS HMAC key
In the Cloud Console, go to Cloud Storage → Settings → Interoperability and create an HMAC key for a service account with read access to the Decode bucket. The key will be registered server-side in MotherDuck so individual analysts never see the credential.
- [ 4 ]
Register the secret and query
Run
CREATE SECRET IN MOTHERDUCK (TYPE GCS, KEY_ID '...', SECRET '...');once. Verify withSELECT count(*) FROM 'gcs://YOUR_BUCKET/...'. Wrap the query as a CREATE OR REPLACE VIEW so the team has a shared, canonical definition of decoded events.
HOW THE SETUP WORKS
Wire decoded GA4 into a MotherDuck workspace in four small steps. The secret is registered once, the views are created once, and the team queries from any browser.
GCP
Run the Decode GA4 installer with the events_external template pointing at your shared GCS bucket.
GCP
Create an HMAC key under Cloud Storage → Settings → Interoperability for a read-only service account.
MotherDuck
In the workspace, run CREATE SECRET IN MOTHERDUCK (TYPE GCS, ...) once.
MotherDuck
Define CREATE OR REPLACE VIEW decode_events AS SELECT * FROM 'gcs://...' for the team.
MotherDuck holds the HMAC credential server-side. Individual workspace members query through the shared secret without ever seeing the underlying key. The Parquet data stays in your GCS bucket and is read on demand — no copy, no replication, no second source of truth.
What you get with MotherDuck
One shared workspace
Workspace membership controls access. The whole analytics team queries the same Decode GA4 bucket through the same credential, with the same persistent views, from any browser.
Persistent server-side secrets
The GCS HMAC key is registered once with CREATE SECRET IN MOTHERDUCK. Analysts query through the workspace without holding credentials locally — central rotation, central revocation.
Canonical views without dbt
CREATE OR REPLACE VIEW decode_pageviews AS ... gives the team one definition of pageviews, sessions, conversions. No dbt project, no scheduled refresh, no orchestration overhead for what is fundamentally a SELECT.
Cloud compute when local hits its limit
Queries that exceed laptop memory — full-history Markov attribution, multi-billion-row joins — run in MotherDuck's cloud DuckDB without any rewrite. Same SQL, more horsepower.
Hybrid local and cloud workflow
Develop a query against the same Parquet path in local DuckDB, push it to MotherDuck when it needs to be shared. Move it back if you want to iterate offline. The path and the schema do not change.
No warehouse, no scan tax
You pay MotherDuck for compute and GCS for storage. There is no BigQuery scan bill on every iteration of an ad-hoc query, and no Snowflake credit consumption sitting idle between questions.
Team-shared cloud workspace for GA4
An analytics team that wants every member querying the same decoded GA4 source, with one credential, one set of canonical views, and no warehouse to maintain. Ad-hoc questions get answered in the same workspace, with the same definitions, by anyone.
Hybrid local-and-cloud development
Build a query offline in local DuckDB against the same GCS Parquet path, then attach to MotherDuck and run the identical SQL when it is ready to share. The Parquet path and the schema are the same in both places, so there is no rewrite step at the boundary.
Shared persistent views without dbt overhead
For teams that do not need a full transformation framework but do need agreed-upon definitions of session, conversion, or attribution, CREATE OR REPLACE VIEW in MotherDuck delivers a shared canonical layer in one statement — no project, no CI, no scheduled job.
How is MotherDuck different from local DuckDB for this workflow?
The query engine is the same. MotherDuck adds a cloud workspace, server-side persistent secrets, shared views, and compute that scales beyond laptop memory. The SQL and the Parquet path are identical, so a query developed locally runs unchanged in MotherDuck. See the local DuckDB integration →
Where does the GCS HMAC credential live?
Inside MotherDuck, registered via CREATE SECRET IN MOTHERDUCK. Workspace members query through the secret but never see the underlying key. Rotation and revocation happen centrally without touching individual machines. Full setup →
Do I need a BigQuery destination as well?
Not for MotherDuck. The events_external template writes Parquet directly to GCS, which is all MotherDuck needs. If you also have dbt or production jobs in BigQuery, the same template can populate both targets in parallel.
Can MotherDuck handle the full GA4 history?
Yes. MotherDuck's cloud DuckDB scales beyond what a single laptop can hold in memory, and the partitioned Parquet layout means most queries only read the date ranges they need. Full multi-year aggregations run server-side without timing out.
Deploy in under 5 minutes
A shared query engine,
without the warehouse.
Subscribe via Google Cloud Marketplace, write the events_external Parquet to GCS, register one secret in MotherDuck, and have the whole analytics team querying decoded GA4 inside the hour.
Google Cloud Marketplace · Usage-based · No monthly minimum