Two Postgres Platforms, Two Different Bets
Two of the better-funded names in serverless Postgres made moves in the same week that, taken together, say something about where enterprise database buying is heading. Neon pushed a public beta of a feature called Realtime, aimed at making Postgres behave like a live data source instead of a store that applications have to keep polling. PlanetScale, separately, added Microsoft Azure as a third cloud option alongside AWS and Google Cloud for both its Postgres and its newer Neki database line. Neither announcement is a flashy new product category, but both chip away at longstanding reasons enterprises reach for something other than Postgres.
The pattern matters because Postgres has spent the past several years absorbing workloads that used to require a separate specialized system: vector search, full-text search, time-series storage, and now, with Neon's push, real-time delivery. Every workload Postgres absorbs is one fewer system a data engineering team has to operate, secure, and reconcile against the primary database. For CTOs managing lean data platform teams, especially at PE-backed companies under pressure to cut tooling spend without cutting capability, that consolidation story is increasingly the more persuasive one, ahead of raw performance benchmarks that rarely decide procurement conversations on their own.
Neon Makes Postgres Talk Back in Real Time
Realtime, now in public beta, lets any deterministic SQL query run as a live subscription rather than a one-time read. Instead of an application polling a Postgres table on a timer to check for changes, a client can subscribe once and receive pushed updates as the underlying data changes, cutting both latency and the load that constant polling puts on the database. Neon shipped a TypeScript SDK with a subscribe function and a useLiveQuery hook for React-style applications, along with support for server-side rendering and instant local writes that update the interface before the server round-trip completes.
By October 16, Neon's changelog showed the feature live in four AWS regions, alongside eleven new models added to its AI Gateway and expanded CJK full-text search inside its Lakebase Search product. Bundling a real-time layer directly into the database removes an entire category of infrastructure, typically a message queue or a dedicated real-time backend, that teams have historically bolted on next to Postgres rather than building Postgres to handle. That is a meaningful simplification for any product team building live dashboards, collaborative tools, or operational monitoring directly on transactional data.
Stripe Picks a Side in the Data Pipeline Wars
Stripe's new Data Pipeline product streams a customer's Stripe account data, charges, subscriptions, invoices, and the rest, directly into a destination database, handling both the initial historical backfill and the ongoing delivery of new events. Neon is now a selectable destination inside the Stripe Dashboard, in public preview and free to start, which means a finance or data team can wire Stripe straight into a Postgres database without building or maintaining a custom extraction job to do it. That is a meaningfully lower-friction path than the reverse-ETL and custom scripts most finance data stacks have relied on until now.
The choice of Neon as a first-class destination is also a signal about where Stripe expects its data customers to be running Postgres. For teams that already lean on Stripe for billing, the integration removes one of the more tedious recurring engineering tasks, keeping a warehouse or operational database in sync with billing events, and replaces it with a managed pipeline Stripe itself operates. It is a small integration in isolation, but it adds another reason for teams standardizing on Postgres to pick Neon specifically rather than a competing serverless Postgres provider.
PlanetScale Goes Where AWS and Google Already Are
PlanetScale's Azure expansion gives customers of its Postgres and Neki database lines the same feature set and region coverage they already had on AWS and Google Cloud, now extended to Microsoft's cloud. Vitess, PlanetScale's original MySQL-compatible sharding layer and the product that built the company's early reputation, is not part of the Azure rollout, which underscores that this move is specifically about Postgres and Neki rather than the full PlanetScale catalog. For enterprises that have standardized procurement, security review, and data residency policies around Azure, the expansion removes a cloud-provider mismatch that could previously have ruled PlanetScale out entirely.
That matters disproportionately for large enterprises, where cloud provider choice is often locked in years before a database vendor is ever evaluated, set by existing Microsoft enterprise agreements, data residency requirements, or a prior cloud consolidation decision made by a different team entirely. A database vendor that only runs on AWS and Google Cloud is invisible to the sizable share of enterprise buyers whose infrastructure sits on Azure by mandate, regardless of how strong the product is on its merits. PlanetScale's move directly targets that invisibility problem rather than adding a new capability to the product itself.
Why Multi-Cloud Postgres Matters to Procurement
Both companies are chasing the same underlying buyer behavior: enterprises increasingly treat the choice of managed Postgres provider as separate from, and secondary to, the choice of cloud. A CTO might run most of the company's infrastructure on Azure for historical or contractual reasons while still wanting Neon's real-time features or PlanetScale's branching and schema-change tooling for a specific application team. Multi-cloud availability turns that preference into something procurement can actually approve, rather than forcing a tradeoff between the best database product and the mandated cloud provider that most data platform teams lose by default.
The broader implication for enterprise data strategy is that the database layer is decoupling from the cloud layer faster than it used to. Vendor lock-in conversations that used to focus on compute and storage increasingly need to account for the database tier separately, since a Postgres provider available everywhere a company's workloads happen to run removes one more argument for staying with an incumbent warehouse or managed instance purely out of inertia. CTOs renegotiating multi-year cloud agreements should treat database portability as a line item worth pricing into that negotiation.
The Databricks Shadow Over Neon
Neon's product decisions do not happen in a vacuum. Databricks agreed to acquire Neon for roughly $1 billion in 2025, when Databricks itself was valued at $62 billion, and Databricks has since grown into a company valued above $190 billion with a lakehouse platform of its own. Realtime and the Stripe integration both extend Neon as a standalone serverless Postgres product, but they also extend the pool of operational data available to whatever Databricks eventually builds connecting Neon into its broader Lakebase and Genie initiatives, which the company has publicly tied to future revenue growth.
For CTOs choosing a serverless Postgres vendor for the next several years, that ownership structure is worth factoring in alongside the feature list. A database acquired by a company with its own competing data platform ambitions carries a different long-term roadmap risk than one still run as an independent business answerable mainly to its own customers. Neon's recent releases suggest Databricks is, for now, investing in Neon's standalone product rather than folding it away, but that posture can change once the acquisition's broader integration plans mature past their current early stage.
