Moving to PostgreSQL used to be mostly about cost — getting off Oracle or SQL Server licensing. That's changed. PostgreSQL is now the default choice for new application builds, AI included, and Microsoft's own investment is one of the clearest signs of it.
For years, if your stack was Microsoft — .NET, Active Directory, Power BI — your database was SQL Server. That's still true for a lot of existing workloads. But new applications, especially anything AI-related, are increasingly being built on PostgreSQL instead, and Microsoft has read the market correctly rather than fighting it.
Microsoft isn't trying to kill off SQL Server. It's accepting that PostgreSQL has become the default for new builds, and making sure that when organisations choose PostgreSQL, they choose it on Azure. So Microsoft now funds core engineering work on the open-source PostgreSQL codebase itself, alongside the usual Azure tooling to host and migrate it.
A lot of organisations have bolted a separate vector database onto their existing systems to handle AI search and embeddings — transactional data in one place, vector data in another, glued together with application code. That split creates real problems: a search result might look relevant but be based on stale data, or an AI agent might act on something that hasn't been checked against your actual governance rules.
Microsoft's approach is to build vector search and model access directly into PostgreSQL itself, so transactional data, analytics and AI queries live in the same governed database rather than being stitched together after the fact. That's a genuinely sound architectural direction, not just a feature checkbox.
Not all "managed PostgreSQL" is the same. The major providers take quite different approaches:
AWS RDS for PostgreSQL — runs standard, unmodified community PostgreSQL, similar in principle to Oracle's OCI approach. No engine-level lock-in; you could pg_dump your way out to any other PostgreSQL host without re-architecting anything.
AWS Aurora and Google AlloyDB — take that same open-source PostgreSQL and wrap it in their own proprietary storage layer. It performs well, but once you're running at scale on Aurora or AlloyDB, you're tied to that provider. Moving off means re-architecting your data tier, not just changing a connection string.
Oracle OCI Database with PostgreSQL — runs standard, unmodified community PostgreSQL on Oracle's own storage hardware. There's no database-level lock-in, which makes it a genuine escape route for existing Oracle customers. The trade-off is that Oracle isn't putting engineering effort into advancing PostgreSQL itself — it's optimising the infrastructure underneath it, not the engine.
Microsoft Azure — funds a dedicated internal team that contributes code directly back into the open-source PostgreSQL project (Microsoft cites 450+ commits to PostgreSQL core over the past 10 years). Because those improvements land in the community version first, anything you build stays portable to any PostgreSQL instance, not just Azure's.
Azure Database for PostgreSQL is the database behind OpenAI's ChatGPT, reportedly serving around 800 million users. That's a useful real-world proof point if you're wondering whether an open-source engine can handle genuine enterprise scale. Three upstream improvements Microsoft has contributed made this workable:
Asynchronous I/O — the storage engine can now pre-fetch data during index scans instead of waiting on each read, which speeds up performance under load.
Cascading read replicas — read replicas can now relay changes to further replicas downstream, allowing scale-out to around 30 replicas without loading up the primary database or lagging behind it.
Faster vacuuming — PostgreSQL's background cleanup process (VACUUM) was optimised to run faster and in parallel across indexes, which matters a lot at high transaction volumes.
Azure Database for PostgreSQL (Flexible Server) is the standard managed offering. The notable improvement here is Premium SSD v2, which separates storage size from IOPS and throughput — previously, cloud storage tied all three together, so you had to buy more disk than you needed just to get acceptable speed. Microsoft's own benchmarks show meaningful latency and throughput gains at the same monthly cost.
Worth being clear on one point: vector search (pgvector, DiskANN) and the azure_ai extension for calling models directly from the database aren't exclusive to the new HorizonDB (still in Public Preview) — they're already available on standard Flexible Server. HorizonDB's real differentiator is architectural: a Rust-based, disaggregated storage layer that separates compute from storage entirely and pushes filter and vector-distance calculations down into the storage tier itself, rather than doing that work in the compute layer. It's built for heavier relational and AI workloads that have outgrown Flexible Server, and it can mirror transactional tables into Microsoft Fabric in real time — without a separate ETL pipeline. Both work with Pebble IT's new pg_ relay and pg_ auto_mv PostgreSQL extensions that will be released publicly shortly.
Elastic clusters. Flexible Server also now supports native sharding — spreading a database across multiple nodes for horizontal scale-out — without rewriting the application. This is Azure's answer to outgrowing a single instance, and it's a genuine alternative to re-platforming onto something like Citus or a distributed database product.
Autonomous tuning. Azure applies machine-learning-driven index and query tuning automatically. For infrastructure teams without a dedicated DBA on staff, this removes a chunk of the ongoing tuning work that would otherwise need to be resourced. Being Oracle partners, we are aware of Oracle's Autonomous Database and how it has landed poorly with customers due to the 'black-box' approach of autonomous tuning. Microsoft doesn't make a song and dance about this like Oracle, probably for this reason. It can help with proactively stamping out performance issues before a human DBA gets actively involved, so it is likely to be of some benefit.
Security, built in rather than bolted on. This is not marketing blurb. Entra ID integration for authentication, Key Vault-backed encryption key management, private endpoints to keep traffic off the public internet, and encryption in transit, at rest and in use. If you've read our piece on database encryption and the quantum threat, this is the kind of platform-level foundation that still needs your own key management and access controls layered on top — it's not a substitute for either.
Availability. Flexible Server carries a 99.99% SLA with zone-redundant high availability as a configurable, standard feature — not something you have to architect yourself from scratch.
The cost difference is real
For a comparable production setup (4 vCores, 128 GiB storage, general purpose tier) in the Australia Southeast region, Azure Database for PostgreSQL comes in at roughly 55% cheaper per month than an equivalent Azure SQL Database. That gap holds across dev/test and high-availability tiers too.
Two reasons for the gap:
1. No licensing premium. A chunk of what you pay for Azure SQL goes toward the SQL Server licence itself. PostgreSQL's cost is purely infrastructure — vCores, memory, storage.
2. Better scheduling. Flexible Server supports automated stop/start, so non-production environments only get charged while they're actually running, not 24/7.
For the full cost breakdown across environments and the assumptions behind it, see our companion article: Why PostgreSQL Flexible Server Can Cut Azure Database Costs by Up to 60% for New Projects. (to be released early July 2026).
Note this is a different comparison to the "up to 58% lower TCO" figure Microsoft quotes on its own Azure Database for PostgreSQL page — that one is Postgres-on-Azure versus running Postgres yourself on-premises or self-managed, not versus Azure SQL. Both figures can be true at once, but they're not interchangeable, so don't quote one to support the other.
Microsoft now offers AI-assisted assessment and conversion tooling for Oracle-to-PostgreSQL migrations, built on top of the open-source ora2pg converter. It's a reasonable starting point for a quick assessment, but an AI layer over ora2pg is not the approach we'd recommend for a production migration. ora2pg does a solid job on structural conversion — tables, basic PL/SQL — but it doesn't reliably handle the harder parts: complex PL/SQL logic, Oracle-specific packages, performance-equivalent indexing strategy, or the kind of data validation that tells you the migration actually worked and not just that it ran. Layering AI-generated suggestions on top speeds up the assessment step, but it doesn't fix those underlying gaps, and it can give a false sense of confidence in a converted codebase that still needs a human expert to walk through it line by line.
Pebble IT's own tooling and migration methodology cover that harder ground directly, which is why we get better outcomes on production migrations than an AI-assisted pass over ora2pg alone.
The bottom line
If you're choosing a database for a new workload, PostgreSQL is now a safe default rather than a workaround. And of the major cloud providers, Microsoft's willingness to invest directly in the open-source engine — rather than just wrapping it in proprietary infrastructure — is what makes Azure worth a serious look, alongside the usual factors of cost, support and existing skills in your team.
Pebble IT helps organisations migrate to PostgreSQL on Azure and Microsoft Fabric
Migrating a database is a high-stakes project. Done badly, it means data loss, downtime and blown budgets. Pebble IT has been running structured, safe database migrations for many years, and we combine that experience with current migration tooling.
Oracle remains a capable platform, but for many organisations the licensing cost, compliance overhead and vendor dependency are no longer worth it. PostgreSQL delivers enterprise-grade capability at a fraction of the cost, with no vendor lock-in.
Microsoft Fabric is also becoming a common destination for organisations consolidating data engineering, warehousing, analytics and AI onto one platform. Whatever's driving your move — cost, modernisation, cloud readiness or a Fabric strategy — talk to us about this or migrating to databricks.
Pebble IT
- Why PostgreSQL Flexible Server Can Cut Azure Database Costs by Up to 60% for New Projects (to be released early July 2026)
Microsoft
- Microsoft Azure Blog: From Commit to Cloud: Powering What's Next for PostgreSQL
- Microsoft Open Source Blog: PostgreSQL Enters Its AI Era
Further reading for those inclined ...
- Kumar, V. & Linster, M. (2026). AI-Ready PostgreSQL 18: Building Intelligent Data Systems with Transactions, Analytics, and Vectors. (AWS Books)
- Keynote: The Distributed PostgreSQL Problem & How Citus Solves It (Youtube)
- Azure Database for PostgreSQL Technical Documentation
