Before we meet the Azure services, we need a shared understanding of what a relational database is and why running one is harder than it looks.

What a database actually is

A database is an organized place to store information so that programs can find it again quickly and safely. A relational database keeps that information in tables, which look like spreadsheets. Each table has columns that describe the kind of data, such as a name or a price, and rows that hold individual records, such as one customer or one order. Tables are connected to each other through shared values called keys. An order row might hold a customer number, and that number points to a row in the customer table. This connection is the “relation” in the word relational.

The language of relational databases

Programs talk to relational databases using a language called SQL, short for Structured Query Language. SQL lets an application ask for data, add new data, change existing data, or remove it. Both PostgreSQL and MySQL understand SQL, although each adds its own dialect and special features. They are both open source, which means their source code is public and a worldwide community improves them.

ACID: the promise that protects your data

Serious databases follow a set of guarantees called ACID. Atomicity means a group of changes either all happen or none happen, like a bank transfer that must both remove money from one account and add it to another. Consistency means the data always obeys the rules you defined. Isolation means two people working at the same time do not see each other’s half-finished work. Durability means that once the database says “saved”, the data survives a power cut. Every feature you will read about in this guide, from write-ahead logs to zone-redundant standby servers, exists to protect these four promises at scale.

Why running your own database is hard

Installing a database on a virtual machine takes an afternoon. Keeping it healthy for ten years takes a team. Someone must apply security patches, plan upgrades, schedule backups, test that those backups can really be restored, watch disk space, tune memory, set up a standby server, practice failover, rotate certificates, and answer the phone at three in the morning. Each task is small, but together they form a permanent job known as database administration.

What “managed” means in practice

In a managed service the cloud provider operates the machines, the operating system, the database engine installation, the backup system, the monitoring plumbing, and the failover machinery. You receive a connection address, a login, and a set of settings that you can adjust. You are still responsible for what lives inside the database: the tables, indexes, users, queries, and data quality. This split of duties is called the shared responsibility model, and we will return to it when we discuss security.

Two engines, one family of managed services, and one deployment model that you should use for every new project.

The two services

Azure Database for PostgreSQL is Microsoft’s managed service for the PostgreSQL engine. Azure Database for MySQL is its managed service for the MySQL engine. Both are built around the same operating philosophy: Microsoft runs the infrastructure, you choose the size and settings, and the service provides automatic backups, built-in security, monitoring hooks, and optional high availability. Because they share a philosophy, many concepts you learn for one transfer directly to the other.

Flexible Server: the deployment model that matters

Older material you may find online mentions “Single Server”, an earlier deployment option. Single Server has been retired for both engines, and Flexible Server is now the model you use for all new work. Flexible Server gives you more control than the older design. You can pick your availability zone, choose between same-zone and zone-redundant high availability, stop the server to save money during quiet periods, schedule your own maintenance window, and connect through private networking. When this guide says “the service” it always means Flexible Server.

Where the services fit among Azure data options

Azure offers many data services. Azure SQL targets the Microsoft SQL Server engine. Azure Cosmos DB targets globally distributed document and key-value workloads. Azure Database for PostgreSQL and MySQL target teams that want the open-source engines, the huge ecosystem of drivers, frameworks, and extensions, and freedom from vendor-specific SQL. If your application already runs on PostgreSQL or MySQL somewhere else, moving to the Azure services is typically the smallest change possible, since your code continues to speak the same protocol.

The current landscape

The services evolve monthly. As of late 2026, the PostgreSQL service supports versions from 13 through 18, with PostgreSQL 18 having reached general availability in November 2025. The MySQL service supports the community versions 5.7, 8.0, and 8.4, with 5.7 only in extended support. Microsoft ships a new service release roughly every month; new servers receive it first, and existing servers receive it during their next scheduled maintenance window. Because details change fast, treat this guide as a map of concepts and confirm exact limits in the official documentation before making a purchase or architecture decision.

The managed wrapper is similar, but the engines underneath have different personalities. Picking the one that fits your workload saves years of friction.

Two engines, two personalities

PostgreSQL is often described as the feature-rich, standards-focused engine. It supports advanced data types such as arrays, ranges, geometric shapes, and rich JSON storage, plus powerful indexing choices, sophisticated query planning, and an extension system that lets the community add whole new capabilities. MySQL is often described as the simple, fast, widely deployed engine. It has a long track record in web workloads, an enormous base of tutorials and hosting support, and a straightforward replication model that many teams already understand.

How to decide

Start from your existing assets. If a vendor product requires MySQL, or your team has ten years of MySQL experience and tooling, stay with MySQL. If you are building a new system that will need advanced querying, strict data integrity features, geospatial data, or vector search for AI, PostgreSQL is usually the more comfortable home. If you are unsure, choose the engine your team can operate and debug confidently, because a well-understood database always beats a theoretically better one that nobody can troubleshoot.

Understanding the moving parts turns the service from a magic box into a system you can reason about.

The big picture

Every Flexible Server deployment has a few essential parts. There is a compute layer, which is the virtual machine running the database engine. There is a storage layer, which holds the data files, the transaction logs, and the temporary files. There is a networking layer, which controls who can reach the server. There is a control plane, which is the Azure management system that creates, scales, patches, and repairs servers on your behalf. Finally, when high availability is enabled, there is a standby copy of the compute and storage ready to take over.

flowchart LR
  APP["Application"] --> NET["Networking Layer: public access or private access"]
  NET --> GW["Gateway and Connection Routing"]
  GW --> CMP["Compute: Database Engine"]
  CMP --> STO["Storage: Data Files and Logs"]
  CP["Azure Control Plane"] -.manages.-> CMP
  CP -. manages .-> STO
  CMP -. replicates .-> SBY["Standby Compute and Storage"]
        

Control plane versus data plane

The control plane is where management actions happen: creating a server, changing its size, turning on high availability, restoring a backup. These actions go through Azure Resource Manager, the same front door used by every Azure resource. The data plane is where your application talks to the database engine using the normal PostgreSQL or MySQL protocol. The two planes are deliberately separate. If the control plane has a hiccup, your running database keeps serving queries, and if your application floods the data plane with traffic, you can still scale the server through the control plane.

Resource hierarchy

Inside Azure, a server lives in a resource group, which lives in a subscription, which belongs to a tenant. A single server can host many databases, and each database holds many tables. Permissions, policies, tags, and cost reports can be applied at any of these levels, which makes governance easier in large organizations.

Choosing the right size is a balance between performance, resilience, and cost, and it can be changed later.

The three tier families

Compute is sold in tiers that describe the ratio of CPU to memory and the intended workload. The Burstable tier is designed for development, testing, and light workloads that are idle most of the time and need short bursts of power. It accumulates credits while quiet and spends them when busy. The General Purpose tier offers a balanced ratio of CPU to memory and suits most production applications. The memory-heavy tier, called Memory Optimized on PostgreSQL and Business Critical on MySQL, offers more memory per virtual core for workloads that cache large working sets, run heavy joins, or serve many concurrent sessions.

Scaling up and down

You change compute size through the control plane. The service provisions the new size and restarts the database, which causes a short interruption. On servers with high availability, recent platform improvements allow the switch to use the standby first, which reduces how long clients are disconnected. In mid-2026 the PostgreSQL service reduced its gateway switch time during failover and scaling from several minutes at worst to under one minute, which is a good example of why you should read the monthly release notes.

How to size sensibly

Begin with your current workload numbers. Measure peak concurrent connections, typical CPU use, memory pressure, and the size of the frequently read data, which is called the working set. If the working set fits in memory, queries are fast because the engine rarely touches disk. If it does not, input and output pressure rises and latency becomes unpredictable. Choose a size that keeps typical CPU under about sixty percent so spikes have room, then revisit monthly using the platform metrics.

Storage is where durability meets performance, and the newest storage option changes how you plan capacity.

What storage holds

The storage layer holds your data files, your indexes, and the transaction logs that record every change. Temporary files used for sorting large results also use space. All data is encrypted at rest by default using strong encryption keys managed by Azure, and you can choose to bring your own keys, which we cover in the security chapter.

Three measurements of storage

Storage is described by three numbers. Capacity is how many gigabytes or terabytes you can store. IOPS, short for input and output operations per second, is how many separate reads and writes the disk can perform each second. Throughput is how many megabytes per second can flow through. A database full of tiny random lookups cares most about IOPS, while a nightly report scanning huge tables cares most about throughput. In traditional disk designs these numbers were tied together: to get more IOPS you had to buy more capacity, even if you did not need the space.

Premium SSD v2: independent scaling

Premium SSD v2 separates the three numbers so you can set capacity, IOPS, and throughput independently. On the PostgreSQL service, Premium SSD v2 reached general availability in April 2026, including support for customer-managed keys and online storage expansion. On the MySQL service, Premium SSD v2 entered private preview in July 2026, and it also brings support for newer compute families. Availability varies by region and compute size, so always check current documentation before planning around it.

Storage autogrow and limits

Storage can be configured to grow automatically as data increases, which protects against the nightmare of a database that stops accepting writes because the disk is full. Growth is usually one-way: you can add storage but cannot shrink it later without migrating to a new server. For that reason, set alerts on storage percentage and plan growth deliberately rather than relying on autogrow as a permanent safety net.

Following one change from application to durable storage reveals why logs, buffers, and replication matter.

Step one: the connection arrives

Your application opens a connection using the server name. The gateway receives it, checks which physical machine currently hosts the server, and forwards the traffic. This indirection matters: after a failover the underlying machine changes but the name stays the same, so your application does not need a new address.

Step two: the engine plans and executes

The engine parses your SQL, plans the cheapest way to answer it, and executes the plan. Changes are first applied to pages held in memory, in an area called the buffer pool in MySQL and shared buffers in PostgreSQL. These in-memory pages are fast but vulnerable to power loss, so the engine cannot rely on them alone for durability.

Step three: the log makes it durable

Before the engine tells your application “committed”, it writes a description of the change to a transaction log. PostgreSQL calls this the write-ahead log, and MySQL’s InnoDB engine uses a redo log. Writing a small sequential log entry is much faster than rewriting a scattered data page, so databases write the log immediately and flush the data pages to disk later in the background. If the server crashes, it replays the log on restart and recovers every committed change. This is the technical heart of the durability promise.

sequenceDiagram
  participant A as Application
  participant G as Gateway
  participant E as Engine
  participant L as Transaction Log
  participant S as Standby
  A->>G: Send change request
  G->>E: Route to primary
  E->>E: Update page in memory
  E->>L: Write log entry to storage
  E->>S: Ship log to standby when HA is on
  S-->>E: Acknowledge receipt
  E-->>A: Report commit success
        

Step four: replication and archiving

With high availability, the log is also shipped to a standby so it holds the same committed changes. With read replicas, the same log stream feeds additional servers that answer read queries. The log is also archived to backup storage continuously, and this archive is what makes point-in-time restore possible, because a base snapshot plus the log can rebuild the database at any moment you choose.

Hardware fails, zones lose power, and software restarts. High availability is the design that keeps your application running through all of it.

What high availability means

High availability, often shortened to HA, is the ability of a system to keep working when one of its parts breaks. For a database this means that if the machine running your server fails, another machine takes over quickly, with no committed data lost. Without HA, a hardware failure means waiting for the platform to rebuild a server, which can take minutes or longer. With HA, a ready-made standby is waiting and takes over in a short, predictable time.

Two HA modes

Flexible Server offers two ways to place the standby. In same-zone HA, the primary and the standby live in the same availability zone, which is one physical data center building within a region. This protects against server-level failures and planned maintenance, but not against loss of the whole building. In zone-redundant HA, the standby sits in a different availability zone, so even the loss of a complete data center does not take your database offline. Zone-redundant HA costs the same compute and storage again for the standby, plus a small latency cost because commits must be acknowledged across zones, but it gives the strongest protection available inside a region.

How failover happens

The service continuously monitors the primary. If it detects a failure, it promotes the standby, which already holds every committed transaction, and redirects traffic. Your application keeps using the same server name. Connections that were open are dropped, so a well-written application must retry. You can also trigger a planned failover yourself to test your application or to move the primary to a different zone. On the MySQL service, newer HA configurations use a dedicated Standard Load Balancer in front of the pair so traffic can be redirected without waiting for DNS changes, which noticeably shortens failover time. On the PostgreSQL service, the gateway switch time during failover and scaling was reduced to under a minute in 2026.

flowchart TD
  A["Primary server fails"] --> B["Platform detects failure"]
  B --> C["Standby is promoted to primary"]
  C --> D["Traffic is redirected to the new primary"]
  D --> E["Application reconnects with retry logic"]
  C --> F["A new standby is built in the background"]
        

Planned versus unplanned events

Unplanned failover is triggered by failures. Planned failover happens during maintenance or when you ask for it. Both result in the same short connection interruption, but planned events let you choose a quiet moment. With HA enabled, maintenance such as minor version upgrades is applied first to the standby, which then takes over, reducing visible downtime.

A backup you have never restored is only a hope. This chapter explains how the service protects your data and how to plan for the worst day.

Automatic backups

Both services take backups automatically with no work from you. A snapshot of the storage is taken regularly, and the transaction logs are archived continuously in between. Together they allow point-in-time restore, which means you can rebuild the database as it was at any second inside your retention window. The retention window is configurable, and the default is seven days with the option to extend to about thirty-five days. Restoring always creates a new server, so your original server is not overwritten, which is a safety feature that lets you compare the old and restored data side by side.

Backup redundancy

Backup storage can be kept redundant inside the region, with copies spread across zones where the region supports it, or it can be geo-redundant, with a copy asynchronously stored in the paired region hundreds of miles away. Geo-redundant backup lets you perform a geo-restore after a regional disaster. The trade-off is that the remote copy is slightly behind, so the amount of recent data you could lose, known as the recovery point, is larger than with in-region protection.

Long-term retention

Some industries must keep backups for years. The PostgreSQL service offers long-term retention backups that can be kept far beyond the normal window, and in 2026 the platform improved the reliability and failure visibility of these backups. Check current documentation for retention limits and region availability, because this area is evolving.

Recovery vocabulary

Designing a recovery strategy

Start from RPO and RTO, not from features. An internal reporting database might accept a day of data loss and a day of recovery time, so default backups are plenty. A payments database might need near-zero data loss and a recovery within minutes, which calls for zone-redundant HA, a cross-region read replica ready for promotion, and regularly rehearsed runbooks. Write the plan down, assign owners, and test it at least twice a year, because configurations drift and people forget.

Who can reach your database, and by which road, is one of the most important decisions you will make.

Two connectivity models

A Flexible Server can be reachable in two main ways. With public access, the server has an address on the public internet, protected by firewall rules that list which client addresses may connect. With private access, the server is injected into a virtual network, which is your own private network space in Azure, and receives only a private address that is unreachable from the internet. Alongside these, private endpoints let you attach a private address from your network to a server through Azure Private Link, which suits organizations that already use private endpoints for other services. In 2026 the services continued to improve migration paths from virtual network integration to private endpoints, including for servers that already have high availability enabled.

DNS: the quiet troublemaker

Private networking depends on private DNS, the naming system that turns a server name into a private address. Many outages in private deployments are not database problems at all. They happen because a client resolves the name to the public address, or to nothing, because the private DNS zone is not linked to the correct network. When connection problems appear in a private setup, check name resolution before anything else.

Encryption in transit

Connections to both services are encrypted using TLS, the same technology that protects websites. Modern versions of TLS are supported, and the MySQL service added TLS 1.3 support even for the older 5.7 version in early 2026. You can require encrypted connections and set a minimum TLS version. Certificates are renewed automatically by the platform, and in 2026 the MySQL service began renewing them earlier in their lifetime to reduce the risk of expiry-related connection failures. Your client applications should trust the current root certificates, and your team should track announcements about certificate authority changes.

Connection pooling

Each connection to a PostgreSQL server consumes memory because the engine dedicates a separate process to it. Applications that open thousands of connections, for example many small microservices or serverless functions, can exhaust memory long before CPU runs out. A connection pooler sits between the application and the database, keeping a small number of real connections and sharing them among many clients. The PostgreSQL service includes a built-in PgBouncer option that you can switch on with a setting, which removes the need to run your own pooler. MySQL uses threads rather than processes, so it tolerates more connections, but a pooling layer in the application or an intermediate proxy is still valuable for bursty workloads.

flowchart LR
  subgraph VNET["Your Virtual Network"]
    APP["Application Subnet"] --> PE["Private Endpoint or Delegated Subnet"]
  end
  PE --> DB["Flexible Server"]
  DNS["Private DNS Zone"] -.resolves name.-> APP
  INTERNET["Public Internet"] -. blocked .-> DB
        

Security is built in layers, so that a failure in one layer is caught by the next.

The shared responsibility model

Microsoft secures the physical data centers, the host machines, the platform software, and the default encryption of data. You secure your identities, your network exposure choices, your database permissions, and your data classification decisions. A common source of incidents is assuming the provider handles something that is actually the customer’s job, such as removing an old firewall rule or rotating a shared password.

Authentication: proving who you are

Both services support traditional database users with passwords. The PostgreSQL service now defaults to SCRAM, a modern password-exchange method that never sends the password itself, for new servers on recent versions. Both services also support Microsoft Entra ID, Azure’s identity system, so people and applications sign in with their organizational identity or a managed identity instead of a stored password. Managed identities are especially valuable because an Azure application can authenticate without any secret in its configuration, and access disappears the moment the identity is removed. Entra group login, introduced in preview in 2025, lets you grant database access to a group so that membership changes flow automatically.

Authorization: deciding what each identity can do

Once a user is identified, the database decides what they may read or change. Follow the principle of least privilege: give each application account only the rights it needs, keep administrator accounts for administrators, and separate accounts for read-only reporting from those that write data. Roles in the database group permissions so you can manage them by job function rather than person by person.

Encryption at rest and customer-managed keys

By default, data, backups, and temporary files are encrypted on disk with keys managed by the platform. For organizations with compliance requirements, customer-managed keys allow you to hold the master key in Azure Key Vault or a hardware-backed managed module, and to revoke access by disabling the key. Recent improvements include automatic key version updates, support for hardware-backed key vaults at higher protection levels on the MySQL service, and a preview of cross-tenant customer-managed keys on the PostgreSQL service. The cost of this control is operational: if your key is deleted or access is lost, the database becomes unreadable, so protect keys with soft-delete, purge protection, backups, and tight access policies.

Threat protection, auditing, and governance

Scaling up means a bigger server. Scaling out means more servers sharing the work. Both services offer ways to scale out reads, and PostgreSQL adds a way to scale writes too.

Read replicas

A read replica is a copy of your server that receives every change from the primary and serves read-only queries. Most applications read far more than they write, so sending reports, search pages, and dashboards to replicas frees the primary for writes. Replication is asynchronous, which means a replica can lag slightly behind the primary. Your application must accept that a user who just saved data might not see it immediately on a replica, and should read from the primary when freshness matters. Replicas can be placed in the same region or a different region, which also helps users who are far from the primary and doubles as a disaster recovery option because a replica can be promoted to become an independent server.

Modern replica features on PostgreSQL

The PostgreSQL service supports virtual endpoints, which give your application a stable name that always points to the current primary or to the replica set, so promoting a replica does not require changing application configuration. Cascading replicas, which are replicas fed by other replicas rather than the primary, reached general availability in 2026, reducing load on the primary when you need many copies or a chain across regions. Logical replication and logical decoding are also available for streaming individual table changes to other systems.

Replication on MySQL

The MySQL service supports read replicas built on the engine’s binary log replication. It also supports data-in replication, which lets a Flexible Server act as a replica of a MySQL server running elsewhere, which is a powerful migration technique, and data-out patterns to send changes to other systems. A recent improvement allows self-service configuration of binary log row metadata, which unblocked several change data capture tools that previously needed support tickets.

Elastic clusters for PostgreSQL

A single server has an upper limit on how much write traffic and data it can handle. Elastic clusters in Azure Database for PostgreSQL address this by spreading data across several nodes, a technique called sharding. Tables are split into pieces based on a chosen key, such as a tenant identifier, and each node stores a share. Queries that include the key go directly to the right node, so adding nodes adds capacity. Elastic clusters reached general availability in early 2026 and gained Terraform support shortly after. They suit multi-tenant software-as-a-service products and high-volume transactional systems, but they require thoughtful data modeling, because the choice of distribution key is difficult to change later.

PostgreSQL’s extension system turns the database into a platform. This chapter shows what the managed service offers and what to be careful about.

What an extension is

An extension is an add-on package that gives the database new abilities, such as new data types, new index methods, or new functions. You allow an extension on the server and then enable it inside a database. The Azure service curates the list of supported extensions, which is why you cannot install an arbitrary one, but the list is long and grows each month.

AI-ready databases

Modern applications often combine ordinary business data with unstructured knowledge such as documents or product descriptions. An embedding turns a piece of text into a list of numbers that captures its meaning, so similar meanings land close together. Storing embeddings in the same PostgreSQL database as your orders and customers lets you filter by business rules and rank by similarity in one query, and it keeps security, backups, and transactions in one place. The platform also publishes a Model Context Protocol server for PostgreSQL, in preview since 2025, to help AI agents interact with the database in a controlled way. Because these features move fast, verify their status before depending on them in production.

Mirroring into analytics platforms

Heavy analytical queries compete with transactions for the same resources. Mirroring in Microsoft Fabric replicates data from the PostgreSQL service into an analytics lakehouse automatically, so analysts can run large aggregations without touching the production server. This pattern separates operational and analytical workloads while avoiding hand-built extraction pipelines.

MySQL extension story

MySQL’s managed service has a smaller plugin surface. Its strengths lie elsewhere: wide compatibility with web platforms, simple replication patterns, and performance features such as Accelerated Logs on higher tiers, which speeds up write commits by using faster storage for transaction logs. If advanced extension features are central to your design, that tilts the choice toward PostgreSQL.

You cannot fix what you cannot see. Observability turns a mysterious slowdown into a clear, answerable question.

Three kinds of signals

Observability uses metrics, logs, and traces. Metrics are numbers sampled over time, such as CPU percentage or active connections. Logs are text records of events, such as slow queries, errors, or logins. Traces follow a single request through several systems. For managed databases, metrics and logs matter most, and you route them through Azure Monitor, which can show charts, send alerts, and forward data to a central logging workspace.

The metrics that matter

Logs and query insight

Slow query logs record statements that exceed a time threshold. The PostgreSQL service offers Query Store, which keeps statistics about queries over time, and Query Performance Insight, a portal view that ranks queries by time consumed and shows how they change. The MySQL service provides slow query logs, audit logs, and performance insight style features as well. Built-in Grafana dashboards arrived in the portal for PostgreSQL in 2026, giving teams ready-made views without building their own. Send logs to a Log Analytics workspace if you want to search across many servers, keep history longer, and correlate database events with application events.

Alerting that people actually respect

An alert that fires constantly gets ignored. Create a small number of meaningful alerts: storage above a safe level, CPU sustained high, failed connections spiking, replication lag, and failover events. Route them to the people who can act, and write a one-page response guide for each. Review alerts quarterly and remove those that never lead to action.

Most performance problems are not about the size of the server. They are about the shape of the queries and the design of the data.

Start with the questions, not the knobs

Performance work follows a loop: find the most expensive queries, understand why they are expensive, change one thing, and measure again. The Query Store and slow query logs from the previous chapter tell you where time goes. Typically a handful of queries account for most of the load, so fixing three or four statements can reduce CPU more than doubling the server would.

Indexes: the biggest lever

Without an index, the engine must read every row of a table to find the ones you asked for, which is called a full scan. With the right index, it jumps directly to the matching rows. Indexes are not free: each one uses storage and slows down writes slightly, because every insert or update must also update the index. Create indexes for the columns that appear often in filters, joins, and sort orders, remove the ones that are never used, and prefer a few well-chosen indexes over many speculative ones. PostgreSQL offers several index types for different shapes of data, such as text search, ranges, and geometry, while MySQL focuses on its well-tuned tree-based indexes.

Reading the query plan

Both engines can explain how they intend to execute a query, listing which tables are scanned, which indexes are used, and how results are joined. Learning to read these plans is the single most valuable database skill. Look for full scans on large tables, estimates that are wildly different from actual row counts, and expensive sorts. Bad estimates usually mean the statistics that the planner relies on are stale, which a routine statistics refresh can fix.

PostgreSQL housekeeping: vacuum

PostgreSQL keeps old row versions around so that readers and writers do not block each other. A background process called autovacuum cleans up the dead versions and refreshes statistics. If autovacuum cannot keep up, tables bloat, queries slow down, and in extreme cases the database must stop accepting writes to protect itself from transaction identifier wraparound. The platform exposes autovacuum metrics and advisor recommendations so you can see tables where vacuum is behind. Tune autovacuum settings for large, heavily updated tables rather than disabling it, and avoid very long-running transactions, which prevent cleanup.

MySQL housekeeping: the buffer pool and purge

In MySQL’s InnoDB engine, performance relies heavily on the buffer pool, the memory cache for data and index pages. A pool too small for the working set causes constant disk reads. InnoDB also purges old row versions in the background, and long-running transactions can delay this cleanup, leading to growth in history. As with PostgreSQL, keep transactions short and review slow queries regularly.

Application-side causes

Many slowdowns originate in the application. A common one is the N+1 pattern, where code fetches a list of one hundred items and then issues one hundred separate queries for the details, instead of one query that joins them. Another is fetching far more columns and rows than the screen displays. Fixing these at the source often yields larger gains than any database setting.

A managed service still needs to be updated. Understanding the update model lets you plan changes instead of being surprised by them.

Monthly service releases

Both services publish a new release roughly each month. A release can include engine minor versions with security and bug fixes, new features, extension updates, and fixes for known issues. New servers receive the release first. Existing servers receive it during their next scheduled maintenance window, which you can customize by choosing a preferred day and hour. Maintenance can sometimes be rescheduled within a limited period, but postponing indefinitely is not an option because security patches must reach every server.

Minor versus major versions

A minor version, such as moving from one patch level to the next, contains fixes and is backward compatible. The platform applies these for you. A major version, such as moving from PostgreSQL 16 to 17 or from MySQL 5.7 to 8.0, changes internal behavior and may remove old features. You choose when to move. The PostgreSQL service supports in-place major version upgrade, and during 2026 it improved reliability for databases with many large objects and extended support to upgrades involving temporary tablespaces, with in-place upgrade to PostgreSQL 18 available globally. For safe upgrades, restore a recent backup into a test server, perform the upgrade there, run your application tests, and measure how long the upgrade takes before touching production.

End of life and extended support

Open-source engine versions eventually stop receiving community fixes. The Azure services handle this by announcing retirement dates and sometimes offering paid extended support for a limited time. MySQL 5.7, for example, is in extended support, and PostgreSQL versions 11 to 13 have received security patches under extended support arrangements. Treat extended support as a bridge to buy time for migration, not as a destination. Track the version support policy page and put retirement dates on your team calendar.

Stop and start for savings

Development and test servers do not need to run at night. Flexible Server lets you stop a server so that compute charges pause while storage and backups continue. A stopped server is automatically restarted after a limited period, so do not rely on this for long-term parking. Automation using scheduled tasks can stop non-production servers every evening and start them each morning.

Moving a live database is like changing the engine of a plane while it flies. Good planning makes it routine.

Know your source and your tolerance for downtime

Migrations fall into two broad styles. Offline migration copies data while the application is stopped, then switches to the new database. It is simple and safe but requires downtime proportional to the data size. Online migration copies the bulk of the data while the source keeps running, then continuously applies new changes until the two are in sync, and only a brief cutover pause is needed. Online migration is more complex but is the choice for systems that cannot be offline for hours.

Tools and approaches

The migration journey

Compatibility checks

Because the services run community engines, compatibility is generally high, but details matter. Check for unsupported extensions, features that require superuser rights that the managed service restricts, storage engines that are not offered, and settings that the platform controls on your behalf. Confirm that your client drivers support the encryption and authentication modes the server requires.

Cloud databases are billed by what you provision, so careful choices pay off every month.

What you are billed for

Charges come from four main places. Compute is billed for the size you provision for each hour the server runs. Storage is billed for the provisioned amount, plus separate charges for extra performance when you use storage options with adjustable IOPS and throughput. Backup storage beyond the free allowance is billed. Network data leaving Azure or crossing regions is billed, which matters for cross-region replicas. A high availability deployment bills for the standby as well, and each read replica is billed as a full server.

Savings levers

Patterns are solutions that many teams have already tested. Anti-patterns are the traps that many teams have already fallen into.

Helpful patterns

flowchart LR
  U["Users"] --> APP["Application Tier"]
  APP -->|writes and fresh reads| PRI["Primary Server with HA"]
  APP -->|tolerant reads| RR["Read Replicas"]
  PRI -->|log stream| RR
  PRI -->|mirroring| LAKE["Analytics Platform"]
  PRI -->|backups| BK["Backup Storage"]
        

Frequent anti-patterns

Concepts become clearer when you see how they combine in realistic situations. These scenarios are illustrative composites rather than descriptions of specific named customers.

If you remember only one chapter, make it this one. These habits separate calm operations from constant firefighting.

When something goes wrong at an awkward hour, a calm, ordered method beats guesswork. This chapter gives you that method.

The golden rule: narrow the problem first

Every incident belongs to one of four zones: the application, the network path, the database engine, or the platform underneath. Asking “which zone is this in?” before changing anything saves hours. A symptom such as “the app is slow” could come from any zone, so gather evidence that proves or eliminates each one. Start with the cheapest checks: is the service healthy according to the Azure status information, did anything change recently, and are other applications affected too?

flowchart TD
  S["Symptom reported"] --> Q1{"Can clients reach the server name?"}
  Q1 -->|No| N["Check DNS, firewall rules, private endpoint, and network routes"]
  Q1 -->|Yes| Q2{"Do connections succeed?"}
  Q2 -->|No| C["Check sign-in method, TLS settings, connection limits, and server state"]
  Q2 -->|Yes| Q3{"Is the server resource-starved?"}
  Q3 -->|Yes| R["Check CPU, memory, storage, IOPS, and long transactions"]
  Q3 -->|No| Q4{"Are specific queries slow?"}
  Q4 -->|Yes| P["Study plans, indexes, statistics, and locking"]
  Q4 -->|No| A["Investigate the application and recent releases"]
        

Common symptoms and their usual causes

Locks and blocking

Databases use locks to keep concurrent work consistent. Usually locks last milliseconds, but one forgotten transaction that holds a lock while waiting for a person or a slow external call can make dozens of other requests queue behind it. The symptom looks like a sudden freeze with low CPU. Look for sessions that are waiting and identify the session at the head of the queue. The fix is usually in the application: keep transactions short, avoid user interaction or network calls while a transaction is open, and always release connections back to the pool.

Deadlocks

A deadlock happens when two transactions each hold something the other needs, so neither can proceed. The engine detects this and cancels one of them with an error. Occasional deadlocks are normal in busy systems, and applications should retry the failed transaction. Frequent deadlocks signal a design problem, most often two code paths updating the same rows in different orders. Make all code paths touch shared rows in the same order and keep transactions small.

When to open a support case

Contact Azure support when evidence points to the platform itself: failovers that did not complete, storage or networking behavior that contradicts documentation, or maintenance that left a server in an unexpected state. Include the server name, region, exact timestamps in a single time zone, error messages, and what you have already ruled out. Good evidence shortens resolution time dramatically.

Prevent rather than cure

Most incidents repeat. Convert each lesson into a permanent safeguard: a new alert, a test in your release pipeline, a policy rule, or a documented runbook step. Run game days, which are planned exercises where the team deliberately triggers a failover, revokes a credential in a test environment, or fills a test disk, and watches how systems and people respond. Teams that practice failure handle real failure with far less stress.

No. It uses the same community engine, but Microsoft operates the machines, patching, backups, and failover. In exchange, you give up operating system access and some superuser-level control, and you can only use the supported extensions and settings.

Single Server was the earlier deployment model for both engines and has been retired. Flexible Server is the current model and the one to use for all new work and for migrations of old servers.

The PostgreSQL service supports recent community versions up to 18, and the MySQL service supports 5.7 in extended support, 8.0, and 8.4. Support lists change, so check the official version support policy before choosing.

Open connections are dropped and then re-established, typically within a short period. Applications with retry logic and healthy connection pools usually recover without user-visible errors, while applications without retry logic may show errors until restarted.

Generally no. Storage can be increased but not decreased on an existing server. To reduce it, you migrate to a new server with a smaller size, which is why growth should be planned rather than automatic only.

They provide read scale and a manual disaster recovery option, since a replica can be promoted. They are not an automatic failover mechanism within a region. Use zone-redundant HA for automatic failover.

Use private connectivity through a VPN or dedicated circuit into an Azure network, combined with private access or a private endpoint, and ensure private DNS resolves the server name for your on-premises clients.

Yes. Data at rest is encrypted by default and connections can be required to use TLS. You can additionally bring your own encryption keys if your compliance rules demand it.

When a single PostgreSQL server cannot handle your write rate or data volume even after tuning, and when your data can be naturally partitioned by a key such as a tenant. For most applications, a single well-tuned server is enough.

Use the burstable tier, stop servers outside working hours, avoid HA and replicas in non-production, and delete environments that are no longer needed.

Within your configured backup retention window, which starts at about seven days by default and can be extended to about thirty-five days. Long-term retention options exist for longer needs on supported configurations.

Yes, they are independent services. Many organizations use each where it fits best, though operating two engines requires skills and tooling for both, so avoid mixing without a clear reason.

Azure Database for PostgreSQL and MySQL give you the open-source engines you already know, wrapped in a platform that handles patching, backups, monitoring, and failover. Flexible Server is the single deployment model to learn. Everything else in this guide, from storage that scales performance independently to elastic clusters, private networking, and vector search, is a tool you add as your needs grow. The most durable skills are not product trivia but engineering habits: design for failure, protect identity and network paths, test your recoveries, read your query plans, and measure before you scale. Because the services change every month, keep the official release notes close and treat any tutorial, including this one, as a map rather than a contract.