Supporting ChatGPT on PostgreSQL in Azure
Affan Dar, Vice President of Engineering, PostgreSQL at Microsoft Adam Prout, Partner Architect, PostgreSQL at Microsoft Panagiotis Antonopoulos, Distinguished Engineer, PostgreSQL at Microsoft The OpenAI engineering team recently published a blog post describing how they scaled their databases by 10x over the past year, to support 800 million monthly users. To do so, OpenAI relied on Azure Database for PostgreSQL to support important services like ChatGPT and the Developer API. Collaborating with a customer experiencing rapid user growth has been a remarkable journey. One key observation is that PostgreSQL works out of box for very large-scale points. As many in the public domain have noted, ChatGPT grew to 800M+ users before OpenAI started moving new and shardable workloads to Azure Cosmos DB. Nevertheless, supporting the growth of one of the largest Postgres deployments was a great learning experience for both of our teams. Our OpenAI friends did an incredible job at reacting fast and adjusting their systems to handle the growth. Similarly, the Postgres team at Azure worked to further tune the service to support the increasing OpenAI workload. The changes we made were not limited to OpenAI, hence all our Azure Database for PostgreSQL customers with demanding workloads have benefited. A few of the enhancements and the work that led to these are listed below. Changing the network congestion protocol to reduce replication lag Azure Database for PostgreSQL used the default CUBIC congestion control algorithm for replication traffic to replicas both within and outside the region. Leading up to one of the OpenAI launch events, we observed that several geo-distributed read replicas occasionally experienced replication lag. Replication from the primary server to the read replicas would typically operate without issues; however, at times, the replicas would unexpectedly begin falling behind the primary for reasons that were not immediately clear. This lag would not recover on its own and would grow to a point when, eventually, automation would restart the read replica. Once restarted, the read replica would once again catch up, only to repeat this cycle again within a day or less. After an extensive debugging effort, we traced the root cause to how the TCP congestion control algorithm handled a higher rate of packet drops. These drops were largely a result of high point-to-point traffic between the primary server and its replicas, compounded by the existing TCP window settings. Packet drops across regions are not unexpected; however, the default congestion control algorithm (CUBIC) treats packet loss as a sign of congestion and does an aggressive backoff. In comparison, the Bottleneck Bandwidth and Round-trip propagation time (BBR) congestion control algorithm is less sensitive to packet drops. Switching to BBR, adding SKU specific TCP window settings, and switching to fair queuing network discipline (which can control pacing of outgoing packets at hardware level) resolved this issue. We’ll also note that one of our seasoned PostgreSQL committers provided invaluable insights during this process, helping us pinpoint the issue more effectively. Scaling out with Read replicas PostgreSQL primaries, if configured properly, work amazingly well in supporting a large number of read replicas. In fact, as noted in the OpenAI engineering blog, a single primary has been able to power around 50+ replicas across multiple regions. However, going beyond this increases the chance of impacting the primary. For this reason, we added the cascading replica support to scale out reads even further. But this brings in a number of additional failure modes that need to be handled. The system must carefully orchestrate repairs around lagging and failing intermediary nodes, safely repointing replicas to new intermediary nodes while performing catch up or rewind in a mission critical setup. Furthermore, disaster recovery (DR) scenarios can require a fast rebuild of a replica and as data movement across regions is a costly and time-consuming operation, we developed the ability to create a geo replica from a snapshot of another replica in the same region. This feature avoids the traditional full data copy process, which may take hours or even days depending on the size of the data, by leveraging data for that cluster that already exists in that region. This feature will soon be available for all our customers as well. Scaling out Writes These improvements solved the read replica lag problems and read scale but did not help address the growing write scale for OpenAI. At some point, the balance tipped and it was obvious that the IOPs limits of a single PostgreSQL primary instance will not cut it anymore. As a result OpenAI decided to move new and shardable workloads to Azure Azure Cosmos DB, which is our default recommended NoSQL store for fully elastic workloads. However, some workloads, as noted in the OpenAI blog are much harder to shard. While OpenAI is using Azure Database for PostgreSQL flexible server, several of the write scaling requirements that came up have been baked into our new Azure HorizonDB offering, which entered private preview in November 2025. Some of the architectural innovations are described in the following sections. Azure HorizonDB scalability design To better support more demanding workloads, Azure HorizonDB introduces a new storage layer for Postgres that delivers significant performance and reliability enhancements: More efficient read scale out. Postgres read replicas no longer need to maintain their own copy of the data. They can read pages from the single copy maintained by the storage layer. Lower latency Write-Ahead Logging (WAL) writes and higher throughput page reads via two purpose-built storage services designed for WAL storage and Page storage. Durability and high availability responsibilities are shifted from the Postgres primary to the storage layer, allowing Postgres to dedicate more resources to executing transactions and queries. Postgres failovers are faster and more reliable. To understand how Azure HorizonDB delivers these capabilities, let’s look at its high‑level architecture as shown in Figure 1. It follows a log-centric storage model, where the PostgreSQL writeahead log (WAL) is the sole mechanism used to durably persist changes to storage. PostgreSQL compute nodes never write data pages to storage directly in Azure HorizonDB. Instead, pages and other on-disk structures are treated as derived state and are reconstructed and updated from WAL records by the data storage fleet. Azure HorizonDB storage uses two separate storage services for WAL and data pages. This separation allows each to be designed and optimized for the very different patterns of reads and writes PostgreSQL does against WAL files in contrast to data pages. The WAL server is optimized for very low latency writes to the tail of a sequential WAL stream and the Page server is designed for random reads and writes across potentially many terabytes of pages. These two separate services work together to enable Postgres to handle IO intensive OLTP workloads like OpenAI’s. The WAL server can durably write a transaction across 3 availability zones using a single network hop. The typical PostgreSQL replication setup with a hot standby (Figure 2) requires 4 hops to do the same work. Each hop is a component that can potentially fail or slow down and delay a commit. Azure HorizonDB page service can scale out page reads to many hundreds of thousands of IOPs for each Postgres instance. It does this by sharding the data in Postgres data files across a fleet of page servers. This spreads the reads across many high performance NVMe disks on each page server. 2 - WAL Writes in HorizonDB Another key design principle for Azure HorizonDB was to move durability and high availability related work off PostgreSQL compute allowing it to operate as a stateless compute engine for queries and transactions. This approach gives Postgres more CPU, disk and network to run your application’s business logic. Table 1 summarizes the different tasks that community PostgreSQL has to do, which Azure HorizonDB moves to its storage layer. Work like dirty page writing and checkpointing are no longer done by a Postgres primary. The work for sending WAL files to read replicas is also moved off the primary and into the storage layer – having many read replicas puts no load on the Postgres primary in Azure HorizonDB. Backups are handled by Azure Storage via snapshots, Postgres isn’t involved. Task Resource Savings Postgres Process Moved WAL sending to Postgres replicas Disk IO, Network IO Walsender WAL archiving to blob storage Disk IO, Network IO Archiver WAL filtering CPU, Network IO Shared Storage Specific (*) Dirty Page Writing Disk IO background writer Checkpointing Disk IO checkpointer PostgreSQL WAL recovery Disk IO, CPU startup recovering PostgreSQL read replica redo Disk IO, CPU startup recovering PostgreSQL read replica shared storage Disk IO background, checkpointer Backups Disk IO pg_dump, pg_basebackup, pg_backup_start, pg_backup_stop Full page writes Disk IO Backends doing WAL writing Hot standby feedback Vacuum accuracy walreceiver Table 1 - Summary of work that the Azure HorizonDB storage layer takes over from PostgreSQL The shared storage architecture of Azure HorizonDB is the fundamental building block for delivering exceptional read scalability and elasticity which are critical for many workloads. Users can spin up read replicas instantly without requiring any data copies. Page Servers are able to scale and serve requests from all replicas without any additional storage costs. Since WAL replication is entirely handled by the storage service, the primary’s performance is not impacted as the number of replicas changes. Each read replica can scale independently to serve different workloads, allowing for workload isolation. Finally, this architecture allows Azure HorizonDB to substantially improve the overall experience around high availability (HA). HA replicas can now be added without any data copying or storage costs. Since the data is shared between the replicas and continuously updated by Page Servers, secondary replicas only replay a portion of the WAL and can easily keep up with the primary, reducing failover times. The shared storage also guarantees that there is a single source of truth and the old primary never diverges after a failover. This prevents the need for expensive reconciliation, using pg_rewind, or other techniques and further improves availability. Azure HorizonDB was designed from the ground up with learnings from large scale customers, to meet the requirements of the most demanding workloads. The improved performance, scalability and availability of the Azure HorizonDB architecture make Azure a great destination for Postgres workloads.New series of monthly Live Webinars on Azure Database for MySQL!
Today we are announcing a new series of monthly Live Webinars about Azure Database for MySQL! These sessions will showcase newly released features and capabilities, technical deep-dives, and demos. The product group will also be addressing your questions about the service in real-time!
Microsoft Azure innovation powers leading price-performance for MySQL database in the cloud
As part of our commitment to ensuring that Microsoft Azure is the best place to run MySQL workloads, Microsoft is excited to announce that Azure Database for MySQL - Flexible Server just achieved a new, faster performance benchmark.Deploying Moodle on Azure – things you should know
Moodle is one of the most popular open-source learning management platform empowering educators and researchers across the world to disseminate their work efficiently. It is also one of the most mature and robust OSS applications that the community has developed and improvised over the years. We have seen customers from small, medium, and large enterprises to schools, public sector, and government organizations deploying Moodle in Azure. In this blog post, I’ll share some best practices and tips for deploying Moodle on Azure based on our experiences working with several of our customers.Migrating from AWS RDS for MySQL to Azure Database for MySQL - Considerations and Approaches
This post covers various strategies for migrating AWS RDS for MySQL to Azure Database for MySQL, how to use them to maximize efficiency and cost savings, different migration considerations, the importance of proper planning and preparation, and potential pitfalls that can arise during the process.Leverage Flexible Server’s Business Critical service tier for mission critical applications
The Business Critical service tier is ideal for mission critical Tier 1 workloads such as ecommerce, financial, or internet-scale applications, that rely heavily on Azure Database for MySQL - Flexible Server to always be available, operational, and resilient to failure. Organizations with mission critical workloads that require low latency, high query per second (QPS), high concurrency, fast failover, and faster throughput should choose to run or build their applications using servers based on the Business Critical service tier.Flexible maintenance options for Azure Database for MySQL (Preview)
Flexible maintenance functionality is designed to provide you with unprecedented control over your maintenance operations. Today, we're pleased to announce preview support for new flexible maintenance options in Azure Database for MySQL!Azure Database for MySQL 8.4 Now Generally Available
Note (January 2026): The Business-Critical service tier referenced in this blog has been rebranded to Memory Optimized. This change reflects updated naming only; the underlying performance characteristics and use cases described here continue to apply. We’re excited to announce that Azure Database for MySQL – Flexible Server now supports MySQL 8.4 in General Availability (GA). This means you can create new MySQL 8.4 servers on Azure fully supported for production workloads. MySQL 8.4 is a long-term supported release from the MySQL community, bringing the latest features and improvements while emphasizing stability. With Azure’s managed service, you get these new capabilities backed by Azure’s enterprise-grade reliability and support. In short, MySQL 8.4 GA opens the door for you to upgrade your databases and future-proof your MySQL environment on Azure. Why Upgrade to MySQL 8.4? Avoid End-of-Support Deadlines: If you’re running MySQL 5.7 or 8.0 on Azure, planning an upgrade is crucial. MySQL 5.7’s community support ended on October 31, 2023, and MySQL 8.0’s end-of-life is April 30, 2026. Azure’s standard support for these versions extends slightly beyond those dates (until March 31, 2026 for 5.7, and May 31, 2026 for 8.0). After those points, servers on 5.7 or 8.0 enter Extended Support, a paid support phase that provides critical fixes for up to three years (through 2029). Running your database in Extended Support means additional costs. Upgrading to MySQL 8.4 now ensures your database stays within standard support for years to come, sparing you the hassle of last-minute upgrades or extended support fees. Benefits of MySQL 8.4: MySQL 8.4 is essentially an evolution of 8.0, so it brings numerous performance enhancements, security patches, and new SQL features that have been introduced since 8.0. Because it’s an LTS release, MySQL 8.4 is designed for stability – making it an ideal target for enterprises. Most applications that work on MySQL 8.0 will be compatible with 8.4 with little to no changes, but with 8.4 you gain improvements in areas like replication, query optimization, and JSON handling (among others) that can boost your application’s efficiency. Moreover, by standardizing on 8.4, you align with the version that will receive updates well into the future. In summary, upgrading means better reliability, availability, and security now, and assured support longevity. Upgrading from MySQL 8.0 (In-Place Upgrade) For current Azure Database for MySQL 8.0 users, moving to 8.4 is straightforward, thanks to our in-place major version upgrade capability. You can upgrade your existing 8.0 server to 8.4 on the same server instance, without dumping and restoring data. Here’s how it works: Upgrade Availability: If you create a new MySQL 8.0 server today (post-GA), the option to upgrade to 8.4 is available immediately in the Azure portal or CLI. For existing 8.0 servers (those created before this GA release), the upgrade capability will become available after your next scheduled maintenance window. The September 2025 platform update is enabling this feature across all regions. Note: Azure will not auto-upgrade your server during that maintenance; it only enables the new version as an option. You remain in control of when to perform the major version upgrade. Performing the Upgrade: Once the feature is enabled for your server, you can initiate the upgrade via the Azure portal, Azure CLI, or PowerShell. The process involves a downtime (the server will be taken offline and restarted on MySQL 8.4), so plan to execute during a maintenance window or low-traffic period. We strongly recommend taking a backup or snapshot before upgrading, as a precaution. For a step-by-step guide and best practices (including how to minimize downtime by using read replicas for the upgrade), refer to the official Azure documentation on https://learn.microsoft.com/azure/mysql/flexible-server/how-to-upgrade. In most cases, upgrading from 8.0 to 8.4 is completed within several minutes. After upgrade, your server retains the same endpoints, configuration, and data – just running on the new MySQL 8.4 engine. Upgrading from MySQL 5.7 (Two-Step Path) Upgrading from MySQL 5.7 to 8.4 requires a two-step approach, since a direct jump is not supported: First upgrade 5.7 to 8.0: Azure MySQL Flexible Server supports in-place major upgrade from 5.7 to 8.0. This moves your server to a supported major version and is a necessary intermediate step (you cannot skip major versions in one go). MySQL 8.0 introduced some changes from 5.7 (for example, stricter SQL modes and a new default authentication plugin), so after upgrading to 8.0, test your application and fix any compatibility issues. Azure’s standard support for 5.7 runs until March 31, 2026, so you should aim to complete this step before then. Then upgrade 8.0 to 8.4: With your server now on 8.0, you can use the in-place upgrade to 8.4 as described above. All Azure 8.0 servers will have the 8.4 upgrade option by the end of the next maintenance cycle (after the feature rollout in September 2025). Plan to perform the 8.0 → 8.4 upgrade at a convenient time, ideally well before MySQL 8.0’s support winds down in 2026. This final step ensures you’re on the latest GA version and out of the legacy support cycle. Some customers may choose to migrate 5.7 to 8.4 by creating a new 8.4 server and importing data (using dump and restore or Azure Database Migration Service). This approach can be useful if you want to reorganize your environment or test in parallel. However, it will likely involve more downtime than the sequential in-place upgrades. Evaluate which method fits your needs – either way, now is the time to start, given that free support for 5.7 ends in less than two years. Support Timeline Summary and Next Steps To recap the support timelines and why upgrading matters: MySQL 5.7: Community EOL: Oct 31, 2023. Azure standard support until: March 31, 2026. After that, servers enter extended support (critical fixes only, with additional charges) until March 31, 2029. Action: Plan to upgrade off 5.7 before Q1 2026 to stay within standard support. MySQL 8.0: Community EOL: Apr 30, 2026. Azure standard support until: May 31, 2026. Extended support then runs to May 31, 2029. Action: Begin upgrading 8.0 instances to 8.4 in the coming months, rather than waiting until the last moment. The upgrade feature is available now (or after one maintenance cycle for older servers). MySQL 8.4: GA start: Sep 2025 (now). This is the recommended target for all MySQL deployments on Azure going forward. It will be fully supported on Azure well beyond 2026, receiving regular updates and improvements as part of the Azure service. Action: Deploy new databases on 8.4 and upgrade existing 5.7/8.0 databases to 8.4 when feasible, to benefit from the latest features and long-term support. Next Steps: Getting started with MySQL 8.4 on Azure is easy. You can create a new Azure Database for MySQL 8.4 server from the Azure Portal or via CLI today. For existing servers, review the https://learn.microsoft.com/azure/mysql/flexible-server/how-to-upgrade to choose your upgrade method (in-place with some downtime vs. replica method for minimal downtime) and schedule a time for the upgrade. By moving to Azure Database for MySQL 8.4, you’re investing in a more stable, performant, and future-proof foundation for your applications. We’re thrilled to see customers embrace MySQL 8.4, and we’re committed to making your upgrade process as smooth as possible. Upgrade with confidence, and leverage the power of MySQL 8.4 in Azure to drive your business forward! For more information or to provide feedback, contact Ask Azure Database For MySQL.
