July 15, 2026
For the last few years, if you wanted to build a RAG pipeline, step one was picking a vector database. Pinecone, Weaviate, Milvus, whatever fit your stack. That was just the starting assumption. In 2026, we don’t think that assumption holds anymore, and it’s worth walking through why.
Snowflake, Databricks, and Google BigQuery have all shipped native vector search and embedding generation directly inside their SQL engines this year. Not as a bolt-on integration you wire up with a client library, but as functions you call in a query. That’s a bigger shift than it sounds like on paper, because it changes the actual buying decision teams are making right now.
What each platform shipped?
Snowflake’s approach is Cortex AI: LLM inference, vector search, and document intelligence exposed as SQL functions, so an analyst can run semantic search or summarize a batch of support tickets without leaving the query editor. Snowflake also brought managed Postgres into the platform (GA in late February), and paired it with a natural-language layer called CoWork that lets business users query governed warehouse data conversationally, no agent engineering required.
Databricks went further on the transactional side. Lakebase, its managed Postgres offering, went GA in early February and gives teams OLTP state, vector search, and model serving in one platform, aimed squarely at agentic applications that need more than a read-only warehouse. Combined with Unity Catalog for governance and Agent Bricks for agent logic, the pitch is that you can build a production RAG or agent product without ever leaving the platform.
BigQuery took the most SQL-native route. The VECTOR_SEARCH function does approximate nearest-neighbor search directly against BigQuery tables, and it’s now paired with AI.EMBED and AI.SIMILARITY, both GA, which handle embedding generation and similarity scoring in a single function call. Google also shipped autonomous embedding generation this year, which keeps an embedding column in sync with its source column automatically. No cron job, no separate pipeline watching for new rows. You store the embedding right next to the data it came from, and BigQuery keeps it current.
Why does this matter more?
The pattern across all three is the same: embeddings live as a column, not a separate system. That’s the actual news here. For years, the standard RAG architecture meant extracting data, generating embeddings somewhere, pushing them into a dedicated vector store, and building a sync process to keep the two in step. That’s a real infrastructure tax, and it’s exactly the layer these platforms are now erasing.
If you’re a team currently evaluating Pinecone or Weaviate against “just do it in the warehouse,” the calculus has changed. A dedicated vector database still wins on raw ANN performance at extreme scale, and it wins when your embeddings need to serve a latency-sensitive, customer-facing application outside your data platform entirely. But for the much more common case, RAG over your own enterprise data that already lives in Snowflake, Databricks, or BigQuery, the case for standing up a second system has gotten a lot weaker. You lose a sync pipeline, a second point of governance, and a second bill.
That last point matters more than people give it credit for.
Governance was always the underrated argument for keeping embeddings in the warehouse. BigQuery’s vector search inherits the same row-level and column-level security policies you already have on the underlying table.
Snowflake and Databricks make the same argument through Cortex and Unity Catalog respectively. When your embeddings sit outside the warehouse, you’re maintaining access control twice. When they sit inside it, you’re not.
What this means for you
None of this means the vector database category disappears overnight. Purpose-built vector engines still have a real edge for massive-scale, low-latency, customer-facing search, and plenty of teams are running hybrid setups on purpose. But the center of gravity has moved.
A year ago, “which vector database should we use” was the default question for a new RAG project. Today, the more common first question I’d expect data teams to ask is whether they need a separate vector database at all, given that the platform they’re already paying for now does it natively.
For data architects and ML platform leads, that’s a real decision point worth revisiting even on projects that are already underway.
If your RAG pipeline was built eighteen months ago against a standalone vector store purely because the warehouse didn’t support it yet, that constraint may no longer be true. Worth an audit before you renew that contract.
What we’d watch next
Two things we’re tracking heading into the second half of the year: whether the in-warehouse vector functions hold up at genuinely large scale (billions of rows, not the demo-sized examples most vendor blog posts use), and whether the pricing models for these AI functions stay predictable as usage grows.
Snowflake has already split AI usage into a separate credits pool, which is worth understanding before you build a production dependency on it. Consumption-based pricing on a feature this new is exactly the kind of thing that looks cheap in a pilot and expensive at scale.
Where we can help
The technology is moving quickly, but the bigger challenge is knowing where it fits into your business. Every organization has different data platforms, governance requirements, compliance obligations, and AI goals. Choosing the right architecture requires more than enabling a new feature.
At Primotech, we help organizations evaluate, design, and implement AI-ready data platforms that align with their business objectives. Whether you’re modernizing your data warehouse, building enterprise RAG applications, or exploring agentic AI, our team works with you to create solutions that are secure, scalable, and built for long-term growth.
If you’re rethinking your AI architecture, let’s start the conversation.
