The ETL Pipeline You’re Running Probably Shouldn’t Exist

Picture your data team’s Monday morning. Someone from the product side wants to know which customer support tickets from last week indicated churn risk. The data team says sure, give us a few days. They need to pull the tickets from the operational database, run them through a sentiment model hosted somewhere else, join the results back to customer records in the warehouse, and surface it in a dashboard. By the time the answer arrives, it’s Thursday, half the at-risk customers have already churned, and the product team has moved on to a different question.

This is not a technology failure. It’s an architecture failure. And it’s so common that most teams have stopped noticing it.

How the Pipeline Became the Default

The multi-step data journey became standard for a sensible reason. For most of the last decade, AI models lived somewhere separate from your data. You had a warehouse for storage and querying, and you had a model endpoint for inference. Getting data to the model meant moving it, transforming it, and routing it correctly. ETL pipelines were the infrastructure you built to manage that movement.

That architecture made sense when those were your only options. The problem is that most teams kept building it long after better options existed, partly because the pipeline was already there, partly because changing it felt risky, and partly because the people who built it had strong opinions about its continued importance. Infrastructure has a way of outliving the conditions that made it necessary.

The Alternative That Most Teams Haven’t Tried Yet

BigQuery now ships with native AI functions built directly into SQL. You can call AI.GENERATE to run a Gemini model against any text in your warehouse, AI.EMBED to create vector embeddings, and AI.SIMILARITY to run semantic comparisons, all inside a standard SQL query, on data that never leaves your BigQuery environment.

What this means in practice: that Monday morning churn risk question becomes a SQL query. You write a SELECT statement, call AI.GENERATE on the ticket text with a prompt asking it to classify churn risk, join to the customer table, and you have your answer in minutes. The data doesn’t move. The model comes to the data. Just the question and the answer, separated by a query.

The functions run inside BigQuery, governed by your existing access controls, billed at query time rather than per API call to an external service. If you’ve been putting off AI features because the pipeline work to support them was too heavy a lift, this is worth a serious look.

What This Actually Changes for ISVs

Here’s the earnest advice part: if you build software for data-driven industries, the gap between “we have the data” and “we’re doing something intelligent with it” is where your competitors are winning or losing. That gap has historically been wide because making it narrow required significant engineering investment. It’s getting narrower by default for teams that update their architecture.

Real-time personalization that responds to what a user just did, not a batch job from last night. Fraud signals that run on every transaction as it inserts, not on a review queue processed after the fact. Customer-facing analytics that include a natural language explanation alongside the numbers, generated at query time. These aren’t new ideas. They’ve just been expensive enough in engineering terms to stay on roadmaps instead of shipping.

The teams most at risk from this shift are the ones with mature ETL pipelines staffed by people who are very good at maintaining them. Those pipelines are doing a job, but the job is moving data to where the AI is. When AI is where the data already is, that job changes. The transition is uncomfortable to plan for, and considerably more uncomfortable to discover after a competitor has already made it.

A Few Things Worth Actually Doing

Audit one feature on your roadmap that requires pipeline work before AI can touch the data. Ask whether BigQuery AI functions could collapse that pipeline into a query. If the answer is yes, build it as a proof of concept before committing to the pipeline architecture.

Look at the support tickets, customer feedback, or unstructured text your product already collects. Ask what you’d do with it if classifying and summarizing it cost nothing and took seconds instead of days. The answer to that question is usually a product roadmap item that’s been waiting for the infrastructure to catch up.

The pipeline isn’t always wrong. High-volume workloads with complex transformations may still need one. But “we’ve always done it this way” is not a good enough reason to keep doing it, and a lot of teams are still doing it that way.

Want to go deeper?