Snowflake Buys Crunchy Data for $250m, Databricks Buys Neon for $1B. The New AI Database Battle.

Two deals. One message: the “AI database” war is officially a Postgres warat least in the opening rounds.

In 2025, Snowflake moved to buy Crunchy Data in a deal widely reported at around $250 million, while Databricks agreed to acquire Neon for about $1 billion. On paper, that’s “data platform company buys database company,” which sounds about as spicy as reading a terms-of-service update.

In reality, it’s a power move in the race to own the full stack of AI-native applicationsespecially the kind powered by AI agents that create, test, deploy, and operate software at machine speed. And yes, the irony is delicious: after a decade of “the database is dead, long live anything-but-SQL,” the future apparently runs on… SQL.

What happened (and why everyone perked up)

Here’s the simple version:

• Databricks + Neon: Databricks announced it agreed to acquire Neon, a developer-first, serverless PostgreSQL company, in a deal reported at around $1B.
• Snowflake + Crunchy Data: Snowflake announced it intended to acquire Crunchy Data, a long-time enterprise Postgres vendor, in a deal widely reported at around $250M. Snowflake positioned the acquisition as the foundation for a new offering often referred to as Snowflake Postgres.

Both acquirers are already giants in analytics and AI platforms. Both targets are deeply rooted in PostgreSQL. That overlap isn’t coincidenceit’s strategy.

Why Postgres is suddenly the star of the AI show

If you’re building modern software, Postgres is the default “just works” database for a huge chunk of teams. It’s trusted, well-understood, and (importantly) it lives close to application workflows. That last part is where the AI plot twist happens.

AI apps don’t just analyze datathey operate on it

Classic data warehouses and lakehouses are amazing at large-scale analytics: dashboards, BI, reporting, feature engineering, and offline model training. But many AI productsespecially agentic onesneed an operational database that can handle:

• Fast reads/writes for user sessions and application state
• Transactional integrity (yes, money still exists)
• Concurrent updates (your AI agent is not the only one typing)
• Fine-grained authorization and governance
• Developer-friendly workflows (local dev, branching, testing, previews)

In other words: AI systems don’t just ask questions. They take actions. And actions need a reliable system of record.

“Agentic” changes the provisioning game

Neon became famous for rethinking Postgres with a more cloud-native, serverless flavorespecially features like fast provisioning and database branching. Those capabilities map well to agentic workflows: agents spin up environments, run experiments, fork datasets, validate outputs, and tear things down without waiting for a human to file a ticket.

Databricks leaned into this point directly in its Neon announcement: AI agents create databases like humans create browser tabsquickly, constantly, and without closing the old ones.

Why Snowflake bought Crunchy Data (and what it signals)

Snowflake’s identity has historically been anchored in the cloud data warehousehigh-performance analytics with strong governance. But AI-native applications pressure platforms to cover more of the “application lane,” not just the “analytics lane.”

Crunchy Data brings serious Postgres credibility: enterprise-ready Postgres offerings, deep compliance posture (including regulated environments), and strong cloud-native tooling. That matters because Snowflake isn’t just chasing “developers who like Postgres.” It’s chasing enterprises that must run Postgres securelywith auditability, policy controls, and operational guarantees.

The practical goal: bring OLTP closer to the AI data platform

Snowflake’s pitch is essentially: “Keep the operational database experience developers want (Postgres), but pair it with the governance and security enterprises demandinside the Snowflake environment.” That’s a direct answer to a common AI deployment headache: sensitive operational data sits in one place, analytics in another, and AI workloads bounce between them with lots of copying, syncing, and risk.

With a Postgres-native offering, Snowflake can aim for a smoother path from transactional workflows to AI workflows without forcing teams to stitch together ten products and three prayers.

Why Databricks bought Neon (and what it’s really after)

Databricks popularized the lakehouse idea: unify data lakes and warehouses, simplify data + AI pipelines, and make everything feel like one coherent platform. But even the best lakehouse doesn’t automatically become a great operational database.

Neon gives Databricks an on-ramp into operational, developer-centric Postgresespecially the kind that scales elastically and supports rapid environment creation. That matters for:

• AI agents that need isolated sandboxes to test actions safely
• Application teams building AI features (chat, copilots, workflows) that require low-latency state
• Continuous experimentation where branching databases is as normal as branching code

From a competitive standpoint, it’s also a way to reduce friction: if developers can build and run app-grade Postgres workloads “in the Databricks universe,” Databricks becomes more than an analytics/ML platformit becomes the place where AI apps live.

The real battle: who owns the “AI app substrate”?

Let’s define the prize. The prize is not “the best query engine.” It’s not even “the best vector search.” It’s owning the default substrate where enterprise AI apps are built, deployed, governed, monitored, and scaled.

Think of the modern AI app substrate as a layered cake (a delicious cake, because we deserve nice things):

1. Data foundation: tables, files, streams, logs
2. Operational store: fast reads/writes, constraints, transactions
3. Model layer: training, fine-tuning, inference, evaluation
4. Retrieval layer: embeddings, indexing, ranking, caching
5. Orchestration: workflows, policies, cost controls
6. App layer: agents, copilots, internal tools, customer-facing AI

Snowflake and Databricks already fight hard in layers 1, 3, and 5. These acquisitions are about strengthening layer 2because without a credible operational database story, “AI apps” end up as demos that fall over the moment a real customer clicks the second button.

But waitaren’t vector databases the “AI database”?

Vector databases (and vector search features inside existing databases) matter a lotespecially for retrieval-augmented generation (RAG). But the “AI database” conversation is broader than vectors.

Most production AI systems still need relational structure for:

• Users, accounts, permissions, entitlements
• Orders, invoices, policies, claims, tickets
• Event logs, conversations, agent actions, approval states
• Metadata around documents and embeddings

Vectors help you find relevant information. Postgres helps you run the business while you do it. The winning “AI database” approach often combines both: store embeddings and metadata, apply filters and permissions, keep transactional truth intact, and serve results quickly.

Concrete examples: what these platforms are trying to make easier

Example 1: An AI support agent that can safely take actions

Imagine a customer support agent that can: read a ticket, fetch account status, check policy rules, draft a reply, and (when approved) issue a refund. That system needs:

• A transactional store for tickets, refunds, and approvals
• Analytics to detect trends (spikes in issues, product regressions)
• Governance so the agent can’t “accidentally” refund everyone named Chris
• Audit trails for compliance

A Postgres layer integrated into a broader AI platform makes that architecture less stitched-together and more repeatable.

Example 2: “Branch-and-try” AI development at scale

Teams building AI features need safe environments to test prompts, tools, policies, and data. A serverless Postgres with branching lets teams create isolated copies of schemas and datasets quickly, run evaluations, and merge only what passes quality and safety checks. That workflow looks a lot like modern CI/CDexcept the database is finally invited to the party instead of being the grumpy neighbor calling in noise complaints.

What changes for customers (and what doesn’t)

What likely gets better

• Fewer integrations: fewer “data gravity” gymnastics between operational databases and AI analytics platforms.
• Cleaner governance: centralized policies and auditing for AI access to structured data.
• Developer velocity: faster provisioning, consistent environments, simpler paths from prototype to production.
• Enterprise readiness: stronger compliance and security for operational AI workloads.

What to watch out for

• Pricing complexity: “unified platform” sometimes means “unified invoice.” Ask hard questions early.
• Portability: the more “magical” the integration, the more you should test exit ramps.
• Operational maturity: running an OLTP database at scale is a different sport than analytics. Execution matters.

Who else is in this AI database battle?

Snowflake and Databricks aren’t fighting in a vacuum. Hyperscalers (and long-established database vendors) are not exactly taking naps. Expect continued pressure from:

• Cloud-managed Postgres and MySQL offerings
• Warehouse and lakehouse competitors expanding into transactional and real-time use cases
• Specialized vector database vendors, plus vector features embedded into mainstream databases
• Data governance and catalog companies making “AI access control” a first-class product category

Translation: this isn’t a two-company cage match. It’s more like a crowded basketball court where everyone insists they’re “next.”

What to expect next (aka: where this gets spicy)

1) “Operational + analytical” becomes table stakes for AI

AI agents will push platforms to offer tighter loops between operational state and analytical intelligence. The winner won’t be the platform that demos the coolest chatbotit’ll be the one that reliably runs real workflows with real constraints at scale.

2) Governance becomes a competitive feature, not a checkbox

As AI touches regulated data, customers will demand policy enforcement, audit logs, and permission-aware retrieval. Platforms that make compliance easier (without slowing teams to a crawl) will win deals.

3) Developer experience becomes enterprise strategy

Neon’s focus on developer-first workflows and Crunchy Data’s credibility in enterprise Postgres show a shared truth: the next platform wave is won by whoever developers love and security teams can tolerate. That overlap is rarelike a unicornbut apparently unicorns are purchasable now.

Conclusion: the new AI database battle is about owning the whole loop

Snowflake buying Crunchy Data and Databricks buying Neon isn’t just “M&A news.” It’s a signal that AI changes what databases must do. The database can’t be just a passive storage engine behind dashboards. It has to be an active, governed, developer-friendly runtime for AI-driven actions.

In the short term, these moves validate PostgreSQL as a central pillar of the AI era. In the long term, they hint at an even bigger shift: the dominant AI platforms will be the ones that collapse the distance between data, decisions, and doing.

Or, put more bluntly: whoever owns the database layer that AI agents actually touch… owns a big chunk of the future.

Experience Add-On (Field Notes): What This Looks Like in Real AI Builds

When you’re reading headlines about the AI database battle, it’s tempting to picture a boardroom chess matchCEOs sliding acquisition pieces around a glossy strategy deck. But the “why” becomes much clearer when you look at what engineering teams run into while shipping AI features that customers actually use.

1) The first surprise: your AI feature becomes an app, not a report

Many teams start with an AI pilot that looks like analytics: summarize tickets, categorize documents, generate insights. The moment it works, stakeholders ask the dangerous follow-up: “Can it do something?” That’s when your AI feature becomes an application with state, permissions, approvals, and rollbacks. You suddenly need a database that can handle fast transactional updateswithout breaking governance. Postgres is often where teams land because it’s familiar, reliable, and flexible enough to model messy real-world workflows.

2) The second surprise: latency isn’t a detail, it’s the product

In production, users don’t experience “AI.” They experience waiting. If your agent takes eight seconds to fetch the right customer entitlements, your fancy model might as well be a fortune cookie. Teams discover quickly that the operational data pathsession state, tool calls, user context, and permission checksneeds to be snappy. A strong operational database story, integrated closely with your AI and data platform, can be the difference between “cool demo” and “daily-use tool.”

3) Branching and safe testing stop being luxuries

Agentic systems are experimental by nature. Teams test prompts, tool policies, routing logic, and data transformations constantly. The safest approach is to isolate environments so experiments don’t touch production. That’s why serverless Postgres conceptsfast provisioning, branching, and forkable databasesfeel tailor-made for the agent era. If you can spin up a clean database instance quickly, run automated tests, and toss it out, your iteration cycle speeds up dramatically (and your on-call engineer sleeps more than twice a week, which is a win for civilization).

4) Governance gets real the moment you store embeddings

RAG systems often start with “Let’s embed documents and search them.” Then legal asks: “Can the AI accidentally retrieve private HR documents for someone in Sales?” Now you need permission-aware retrieval, metadata filters, audit logs, and consistent access control. Teams frequently keep embeddings and metadata tied to relational rules because the relational system already knows who can see what. This is where a platform-level approachcombining operational databases, governance, and AI toolingbecomes extremely attractive.

5) The big lesson: platforms win when they make the whole loop boring

The best developer experience is the one where the hard parts feel boring: spinning up data environments, enforcing policies, connecting apps to governed data, tracking agent actions, and auditing outcomes. Most teams don’t want ten separate services with ten separate auth systems and ten separate dashboards. They want fewer moving parts, clear guarantees, and fast iteration. That’s the heart of the new AI database battle: whoever makes the end-to-end AI app lifecycle simplerespecially the operational database layerwins mindshare, workloads, and eventually budgets.

So yes, the headlines are about $250M and $1B. But the day-to-day story is about something more practical: making AI systems trustworthy, fast, and shippable. Postgres just happens to be the battle-tested workhorse both sides want in their stable.