The unglamorous thing that quietly runs your analytics
Most marketing teams never think about database migrations. That's fair. When you're tuning campaigns, writing content, and staring at GA4 dashboards, the schema underneath your data feels like someone else's job. And for a long time, it was. If you wanted a new column, a new table, or a restructured dataset, you filed a ticket and waited for engineering.
That waiting is the bottleneck. It's the reason so many marketing analytics projects die in a spreadsheet. The insight was there, but the plumbing to make it repeatable never got built, because building the plumbing required someone else's roadmap.
Tools like sqlite-utils, Simon Willison's command-line tool and Python library for working with SQLite databases, exist to shrink that gap. Its 4.0 release, in July 2026, added a structured mechanism for evolving a database's schema over time, alongside nested transactions and compound foreign keys. The reason we're writing about a database utility on a marketing blog is simple: the teams that win at analytics are the ones who can change their own data model when the questions change.
What a migration actually is, in marketing terms
Strip away the jargon and a database migration is just a controlled change to the shape of your data. You add a column. You rename a field. You split one table into two. You backfill historical rows so the old data matches the new structure.
This happens constantly in marketing work, whether you acknowledge it or not. GA4 sends you an event. You decide you also want to track the campaign variant that drove it. Now your table needs a new field, and every downstream query, dashboard, and automation that reads that table has to survive the change. Do it by hand and you'll break something. Do it with a migration mechanism and the change is versioned, repeatable, and reversible.
That last word matters. The fear that stops marketers from touching their own data structures is the fear of breaking production. Migration tooling exists precisely to make structural change boring and safe instead of risky and manual.
Why SQLite belongs in a GA4 and BigQuery workflow
We live in BigQuery for GA4 analysis. That won't change. BigQuery is where the raw GA4 export lands, where the event-level data is queryable at scale, and where the heavy joins happen.
But BigQuery is not always the right place to prototype. It's a warehouse, not a scratchpad. When you're figuring out the shape of a new dataset, testing a transformation, or building a small reference table that maps campaign names to human-readable labels, spinning up cloud infrastructure for every experiment is overkill. A local SQLite file is fast, free, and disposable. You can iterate on the structure in seconds, get it right, and then push the finished shape up to BigQuery.
Think of it as two roles. SQLite is where you design and rehearse the data model. BigQuery is where you run it at scale against real GA4 volumes. Migration tooling is what lets you rehearse quickly, because it turns schema changes into one-line commands instead of blocks of hand-written DDL.
The pattern we use: prototype locally, promote deliberately
Here is the workflow this enables, and it's the reason database migrations deserve a marketer's attention.
You pull a sample of your GA4 data, either from the BigQuery export or an API. You load it into a local SQLite database. You start shaping it: adding the derived columns you actually want to report on, splitting messy event parameters into clean fields, building lookup tables for your campaign taxonomy. Because the tooling makes each change explicit and repeatable, you're not just hacking a one-off file. You're writing a definition of the transformation.
Once the shape is right, that definition becomes the blueprint for the production pipeline in BigQuery. You've de-risked the structural decisions before they ever touch your warehouse or your live dashboards. The migration you rehearsed locally is the migration you promote.
This is the same instinct behind feature engineering on the GA4 export: the raw data is not the finished data model, and the gap between them is work an analyst can now own. Structural work that used to require a ticket sits inside the analyst's own toolkit.
Where n8n comes in
The missing piece is orchestration. A migration tool changes the data; something has to run it on a schedule and connect it to everything else. That's where n8n earns its place.
A practical n8n workflow for this looks like a sequence of small steps: a trigger fires on a schedule, an HTTP or export step pulls the latest GA4 data, an execute-command step runs your migrations and transformations against a working database, and a final step loads the cleaned, correctly-shaped result into BigQuery. If a step fails, n8n tells you, and nothing silently corrupts your warehouse.
The important idea is that each of these steps is small, inspectable, and owned by the marketing analyst. You're not handing off a black box. You're assembling a pipeline out of parts you understand, where the database migration step is just one node among several. When the reporting question changes next quarter, you edit that node. You don't file a ticket. The same connective logic is what lets an LLM read the result directly — the pattern we described in connecting Claude to Google Ads, BigQuery and GTM over MCP.
What this looks like in practice
That verification discipline is exactly what this article is about. Every event fired by GTM has an expected shape. GA4 collects it. The BigQuery export lands it. And you check, event by event, that what arrived matches what was intended. When you're doing that kind of verification, the ability to reshape and query data quickly is not a luxury. It's how you catch the form submission writing to the wrong field, or the blog event that lost a parameter somewhere in the chain.
A local, fast, migration-friendly database is a natural companion to that work, because it lets you pull a slice, inspect its true structure, and confirm the shape before you trust the dashboard built on top of it. That's the honest scope of it: a verified event pipeline, not a magic machine. But the mindset carries directly into any GA4 analytics project. Own your data model. Verify the shape. Make structural change cheap.
The real reason marketers should care
The headline says database migrations, but the subject is independence. Every time your analytics work depends on someone else changing a schema for you, your reporting moves at the speed of another team's backlog. Every time you can safely reshape your own data, your reporting moves at the speed of your own questions.
Modern migration tooling, a local database for rehearsal, a warehouse for scale, and an orchestrator to tie it together is a stack a marketing analyst can actually own end to end. That's the shift worth caring about. Not the version number of any single tool, but the fact that the boundary between analyst and engineer keeps moving in the analyst's favour.
You don't need to become a database administrator. You need to stop treating the shape of your data as something you're not allowed to touch.
Talk to us
If you're building GA4 and BigQuery pipelines and you're tired of waiting on engineering to reshape your data, this is the kind of work we do. We can help you design a pipeline you own, from event verification through to automated transformation, and connect it to Claude via MCP for analysis on top. Take a look at what we do and get in touch — let's talk about your analytics and MCP implementation.