These are two Azure services that run MySQL and PostgreSQL for you as managed cloud databases.

A database is an organised place to keep information so that programs can store it, find it and change it quickly and safely. A relational database keeps its information in tables, much like spreadsheets. Each table has columns that describe the kind of information and rows that hold the actual records. Tables can be linked to one another, which is why they are called relational.

MySQL and PostgreSQL are two very popular open-source relational databases. Open source means that anyone may read, use and improve the software without paying a licence fee. Thousands of websites, mobile apps, shops and business systems around the world are built on one of these two. Because developers already know them, companies often want to keep using them when they move to the cloud.

Azure Database for MySQL and Azure Database for PostgreSQL are Microsoft’s managed versions. “Managed” means Microsoft handles the machines, the operating system, the database installation, patching, backups, failure recovery and many monitoring tasks. You decide the size of the server, create databases and tables, connect your applications and manage who may do what. The product you will use today is called Flexible Server for both databases.

Words you will meet again and again

To appreciate a managed service, look at the chores it removes from your plate.

When a team installs a database on its own virtual machine, a long list of jobs follows. Someone must pick the machine size, install the operating system and database software, apply security patches, schedule backups and test that those backups can really be restored. Someone must watch the disk so it does not fill up and build a second server in case the first one dies. These jobs never end, and a mistake in any of them can cause data loss.

Many companies do not have a full-time database administrator. Even those that do prefer their experts to spend time on designing good tables and fast queries rather than replacing disks and installing patches. A managed service lets a small team run a serious, reliable database.

Both are excellent, and the right choice usually depends on your application and your team.

MySQL became famous as the database behind many websites and content systems. It is known for being simple to set up, fast for straightforward reading and writing, and widely supported by hosting tools. PostgreSQL, often called “Postgres”, is known for its rich feature set, strict standards, advanced data types and a huge ecosystem of extensions that add new abilities.

The first big decision is how much brainpower and memory your database server needs.

The compute of a database server is made of virtual cores, often called vCores, and memory. Cores do the thinking, and memory acts like the desk space where the database keeps its most-used data close at hand. A database with a lot of memory can answer many questions without going to the slower disk.

Choices made at creation time

A database is only as fast as the disk behind it, so storage deserves its own thought.

Data, indexes and logs of the database live on storage that Azure attaches to the server. You choose the size in gigabytes or terabytes. Storage can be increased later but, in general, it cannot be reduced, so start with a sensible amount and grow when needed. Many servers also offer an option called storage auto-grow, which automatically adds space before the disk fills up, helping to avoid a sudden outage.

IOPS means input and output operations per second, which is the number of small reads and writes the disk can handle each second. A busy shop database that serves thousands of orders needs many IOPS. Each server size and storage size comes with an included amount of IOPS, and some configurations allow you to pay for more when your workload needs it.

Behind a single connection address, several parts work together to keep your database running.

When you create a Flexible Server, Azure starts a virtual machine that runs the MySQL or PostgreSQL engine inside a managed container environment. Your data lives on remote storage that is separate from the machine itself. Because the storage is kept apart from the compute, Azure can replace a broken machine and attach the same storage to a fresh one without losing your data.

flowchart TD
  A["Application"] --> B["Server Name and Firewall or Private Network"]
  B --> C["Database Engine: MySQL or PostgreSQL"]
  C --> D["Data and Index Storage"]
  C --> E["Transaction Log"]
  D --> F["Automatic Backups"]
  E --> F
  C --> G["Monitoring and Metrics"]
        

Transactions and the promise of safety

Both engines follow a set of rules called ACID, which stands for atomicity, consistency, isolation and durability. In simple words, a group of changes either happens completely or not at all, the data always follows its rules, simultaneous users do not corrupt each other’s work, and once a change is confirmed it is not lost. Transferring money between two accounts is the classic example: the money must leave one account and arrive in the other, never just one of the two.

Machines fail, so a good design plans for it before it happens.

Availability is the share of time your database is ready to answer. A server with high availability enabled has a hidden twin, called a standby, that continuously receives every change made on the main server, which is called the primary. If the primary fails, Azure switches to the standby automatically, and applications reconnect to the same server name after a short pause.

flowchart LR
  APP["Application"] --> EP["Same Server Name"]
  EP --> PRI["Primary Server in Zone 1"]
  PRI -- "continuous copy of changes" --> STB["Standby Server in Zone 2"]
  PRI --> ST1["Storage Copy"]
  STB --> ST2["Storage Copy"]
        

What happens during a failover

High availability protects against failures, but only backups protect against mistakes.

Suppose a developer runs a command that deletes the wrong table. The standby faithfully copies that deletion, so the standby is no help. Backups are what let you go back to the moment before the mistake.

Flexible Server takes care of backups automatically. It takes regular snapshots of the data and continuously saves the transaction log. Combining the nearest snapshot with the log lets you restore the database to any chosen second within the retention period. The retention period is seven days by default and can be extended, up to a maximum of thirty-five days.

Where backups are stored

By default, backups are kept in locally redundant or zone-redundant storage, depending on your setup. You can also choose geo-redundant backup, which keeps a copy in a paired region far away. This allows a geo-restore, in which you build a server in another region after a regional disaster. The geo option must be selected when the server is created.

When more users arrive, you can scale up, scale out for reading, or both.

Scaling up, also called vertical scaling, means moving to a server with more cores and memory. In Flexible Server this is a simple change of size. The server restarts briefly while it moves to the new size, so it is best done during a quiet period. Scaling up is the easiest path, and it often solves problems for a long time.

Scaling out for reads uses read replicas. A read replica is an extra server that continuously receives changes from the main server and keeps its own copy of the data. Applications send their read-only questions, such as showing a product list or building a report, to the replicas, while all changes still go to the main server. This is a very effective way of protecting the primary from heavy reporting queries.

flowchart LR
  W["Application Writes"] --> P["Primary Server"]
  R1["Application Reads"] --> RR1["Read Replica 1"]
  R2["Reports and Dashboards"] --> RR2["Read Replica 2"]
  P -- "asynchronous copy" --> RR1
  P -- "asynchronous copy" --> RR2
        

A database should be visible only to the applications that truly need it.

Flexible Server offers two main ways of connecting, and you choose one when you create the server. Understanding the difference early saves a lot of rework, because changing it later can mean building a new server.

Encrypted connections

Whatever path you use, connections can be protected with TLS, which scrambles the traffic so that nobody listening on the network can read it. Servers support modern versions of TLS, and you can require encrypted connections so that clients without encryption are rejected.

Strong security comes from several small walls, not one big wall.

Signing in

Every server has an administrator account created with a password at set-up time. Many teams also enable Microsoft Entra authentication. With Entra, people sign in with their normal work identity, and applications running in Azure can use a managed identity, which is an identity given by Azure that needs no stored password. This removes secrets from configuration files and makes it easy to remove access when someone leaves.

Encryption

Data at rest, including backups, is encrypted with strong AES 256-bit encryption by default using keys managed by Microsoft. If your rules require control over keys, you can use customer-managed keys stored in Azure Key Vault. Data in transit is protected by TLS.

A healthy database is one you keep an eye on before users start complaining.

Azure Monitor collects numbers from your server automatically. These metrics show how busy the processor is, how much memory and storage are used, how many connections are open, how many reads and writes the disk performs and whether replicas are keeping up. You can draw charts of them and create alerts that send a message when a number crosses a limit.

Finding slow queries

Most performance problems come from a small number of slow queries. Both services can record statements that take longer than a chosen time into a slow query log. PostgreSQL also offers Query Store and a tool to show the statements that use the most time, and both can send their logs to Log Analytics, where they can be searched and charted. Look for queries that run very often, run very long or read far more rows than they return.

Keeping software fresh and secure is a steady job, and the platform helps with it.

Azure regularly applies updates to the operating system, the database engine’s minor versions and the platform itself. You can pick a custom maintenance window, such as early Sunday morning, so that the short restart that sometimes goes with an update happens when few people are using your application. Some updates are urgent security fixes and may be applied outside the usual cycle.

Major and minor versions

A minor version contains fixes and small improvements and is applied by the platform. A major version, for example moving from one big release number to the next, brings larger changes and is done by you when you decide. Each major version has an end-of-life date after which it no longer receives fixes, so plan upgrades well ahead. Flexible Server supports in-place major version upgrades for PostgreSQL and MySQL in many cases, and you should always test an upgrade on a restored copy first.

Extensions in PostgreSQL

One of the great strengths of PostgreSQL is extensions, which add new abilities to the database. Azure allows a curated list of supported extensions that you switch on yourself. Examples include maps and geographic queries, text search helpers, scheduling of recurring jobs, and vector storage for artificial intelligence similarity search. Since the platform controls the server, only approved extensions are available, so check the supported list before designing around one.

The bill for a database is built from a few clear pieces, and each one can be managed.

Most teams do not start from nothing, so moving an existing database safely is a key skill.

Migration means moving a database from where it lives now, such as a server in your office, another cloud or a virtual machine, into Azure. The two main concerns are keeping every record correct and keeping the downtime short. The right approach depends on the size of the database and how long the application can be offline.

flowchart LR
  S["Source Database"] --> M["Migration Tool"]
  M --> T["Azure Flexible Server"]
  S -. "ongoing changes in online mode" .-> M
  T --> V["Validation and Testing"]
  V --> C["Cutover of Application"]
        

Experienced teams keep returning to a handful of reliable ways of using managed databases.

flowchart TD
  U["Users"] --> W["Web Application"]
  W --> CA["Cache"]
  W --> POOL["Connection Pool"]
  POOL --> PR["Primary Server for Writes"]
  POOL --> RP["Read Replicas for Reads"]
  PR -- "replication" --> RP
        

These services quietly run many of the apps and sites you already use.

These tempting shortcuts regularly cause outages, leaks or surprise bills.

Follow these steps when setting up a new production server.

Azure SQL Database runs Microsoft’s own SQL Server engine. Azure Database for MySQL and PostgreSQL run the open-source engines. Pick the one that matches the database your application already uses or your team knows.

Yes. Because these are real MySQL and PostgreSQL engines, standard drivers, command-line clients, graphical tools and frameworks keep working. You only change the connection details.

No. A standby exists only to take over on failure and is not available for your queries. Read replicas are active servers used to share reading work. Many production systems use both.

Usually a brief restart that lasts from several seconds to a couple of minutes. Applications with retry logic ride through it with a small delay. Schedule changes during quiet hours.

In general, no. Storage can be increased but not decreased. To use less storage you would create a new smaller server and migrate the data, so avoid heavily over-provisioning.

The default is seven days, and it can be extended up to thirty-five days. For longer retention, export logical backups to separate storage on your own schedule.

Yes. Data on disk and in backups is encrypted at rest automatically, and connections can be encrypted with TLS. You may use your own keys from Key Vault if your rules require it.

Only if your laptop can reach the virtual network, for example through a VPN, a private connection to your office network or a jump machine inside the network. This is by design and keeps the database off the public internet.

Managed services support a controlled list. Check the supported extensions and parameters first. If something truly essential is missing, a database on a virtual machine that you manage yourself may be the better home, at the cost of doing all the maintenance.

If nothing forces a choice, PostgreSQL is a popular default because of its flexibility and extensions. If your framework or team is built around MySQL, stay with MySQL. Both are well supported on Azure.

Azure Database for MySQL and PostgreSQL gives you the open-source databases you already know, with Microsoft running the heavy chores underneath. You choose an engine, a compute tier and storage, decide how the server is reached, and switch on high availability and backups to match the importance of your data. From there, replicas, caches and connection pools help it grow, while monitoring, careful security and steady maintenance keep it healthy. A little planning at the beginning prevents most of the pain that teams feel later.