They are fully managed database services in Azure that run the real open-source PostgreSQL and MySQL engines, so you can use familiar tools and skills without running the servers yourself.

First, what is a database?

A database is an organized place to keep information so that programs can store it, find it, and change it quickly and safely. Most business applications use a relational database. In this kind of database, information lives in tables, which look like spreadsheets. Each row is one record, such as one customer, and each column is one detail, such as a name or an email address. Programs talk to the database using a language called SQL, which lets them ask questions like, “Show me all orders from last week.”

Two famous engines

PostgreSQL, often called Postgres, is known for correctness, rich features, and the ability to be extended with add-ons. MySQL is known for speed, simplicity, and its huge popularity with websites and web applications. Both are open source, which means anyone can use them without paying a license fee. Both have been trusted by large companies for decades.

What “managed” means

If you install PostgreSQL or MySQL on your own server, you must also look after that server. You install the operating system, keep it patched, set up backups, build a standby copy for emergencies, watch the disk space, and wake up at night when something fails. A managed service moves most of that work to Microsoft. You still design your tables, write your queries, and manage your users. Azure handles the machines, the operating system, the database software updates, the backups, and the machinery for high availability.

One name, one model: Flexible Server

Both services today use a deployment style called Flexible Server. It gives you more control over the maintenance schedule, the high availability setup, the network, and the cost than the older Single Server style, which Microsoft has retired for both engines. When you read documentation or create a new database in Azure, you will be working with Flexible Server.

What you get

• The real engines. Your existing drivers, tools, and skills keep working.
• Automatic backups and the ability to restore to any moment within your retention period.
• High availability with a standby server in another zone that takes over automatically.
• Read replicas to share heavy reading traffic and to prepare for disasters.
• Security built in, with encryption, private networking, and Microsoft Entra ID sign-in.
• Scaling choices for compute and storage, with stop and start options for saving money.

To see why these services matter, picture a small team trying to run their own database server for the first time.

The long list of jobs nobody sees

A database server sounds like one program, but running it well involves dozens of quiet jobs. Someone must install and patch the operating system. Someone must update the database software when security fixes arrive. Someone must schedule backups, copy them to a safe place, and, more importantly, test that they can be restored. Someone must build a second server and write the steps to switch to it if the first one dies. Someone must watch disk space, memory, and slow queries. Someone must be on call.

Each of these jobs is simple on its own. Together, they are a full-time responsibility, and mistakes are expensive. A missed backup is discovered only on the day it is needed. A full disk stops the whole application at the worst moment.

What Azure took over

Who benefits most

Small teams gain because they get professional-grade reliability without hiring a database administrator on day one. Large companies gain because they can run hundreds of databases with a small operations team and consistent standards. Teams moving from their own data centers gain because their applications keep working with the same open-source engines, with very little rewriting.

Every technology has its own small language. Learn these words once, and the rest of this guide, and the Azure documentation, will read easily.

The ACID promise

Relational databases are famous for a promise called ACID. Atomic means a transaction is all or nothing. Consistent means the data always follows your rules. Isolated means several people working at once do not see each other’s half-finished work. Durable means once the database says “saved”, the data survives even a sudden power loss. Both PostgreSQL and MySQL, with the standard storage engine, keep this promise, which is why banks and shops trust them.

A flexible server is more than one machine. It is a small system of cooperating parts, with services around it that protect, copy, and secure the data.

flowchart TD
    APP["Applications and services"] --> POOL["Connection pooler"]
    POOL --> EP["Server endpoint with public or private access"]
    subgraph SRV["Flexible Server"]
        PRI["Primary server running the database engine"]
        STB["Standby server in another zone"]
        DSK["Premium SSD storage"]
    end
    EP --> PRI
    PRI -->|"synchronous log shipping"| STB
    PRI --> DSK
    PRI -->|"asynchronous replication"| RR["Read replicas"]
    PRI --> BKP["Automated backups and log archive"]
    BKP --> GEO["Geo-redundant backup copy"]
    KV["Key Vault"] -.->|"customer managed keys"| SRV
    ENTRA["Microsoft Entra ID"] -.->|"sign in"| EP
    MON["Azure Monitor and Log Analytics"] -.->|"metrics and logs"| SRV
    

Read the diagram from the top. Applications reach the server through its endpoint, often through a connection pooler that keeps the number of open connections healthy. Behind the endpoint is the primary server, which runs the database engine and keeps its data on fast Premium SSD storage. If high availability is turned on, a standby server in another zone receives every change as it happens. Read replicas receive changes a little later and serve read-only traffic. Backups and the continuous log archive are stored separately, optionally with a copy in another region. Key Vault, Microsoft Entra ID, and Azure Monitor sit around the server and add keys, identity, and visibility.

The compute side

The primary server is a virtual machine managed by Azure that runs only the database engine. You choose its size by picking a compute tier and a number of vCores. You cannot log in to the operating system, but you can adjust many engine settings through server parameters.

The storage side

The data and the transaction logs live on managed Premium SSD storage that you size and that can grow over time. The storage service itself keeps several copies of every block, which protects against drive failure. The amount of storage you choose also decides how many IOPS you get, so storage size is both a capacity decision and a performance decision.

The availability side

High availability adds a second, hidden server called the standby. It is not for your queries. It exists only to take over. Read replicas are different: they are visible servers that you can query, designed to share reading work and to help with recovery planning.

The protection side

Azure takes regular backups of the data and archives the transaction log continuously. Together they make point-in-time restore possible. You can choose where backups are stored: in one zone, spread across zones, or copied to another region.

The management side

Everything you create goes through Azure Resource Manager, the same front door used by all Azure services. The server, its settings, its firewall rules, and its tags appear as normal Azure resources that you can control through the portal, command line, or templates.

Both are excellent. The best choice usually depends on your application, your team’s experience, and the features you need.

When PostgreSQL is a natural fit

• Your application needs advanced queries, window functions, or strong data rules.
• You need maps and location queries, using the PostGIS extension.
• You are building AI features that store and search embeddings, using the pgvector extension.
• Your team wants a database that can be shaped with extensions for special needs.

When MySQL is a natural fit

• You run a popular web platform or content system that was built for MySQL, such as many shop and blog platforms.
• Your team already knows MySQL well and your application uses its syntax and tools.
• Your workload is mostly simple reads and writes at high volume, and you want many read replicas.
• You are migrating an existing MySQL system and want the smallest possible change.

The honest rule

If your application already uses one of the two engines, stay with it. Changing engines means rewriting queries, testing behavior differences, and moving data, which is costly. If you are starting a brand new project with no strong preference, PostgreSQL’s wider feature set and extension system make it a popular default, while MySQL remains a smart choice for web workloads with strong existing tooling.

Choosing the right size is the most important cost and performance decision you will make for a database server.

Three compute tiers

The Burstable tier works like a savings account for CPU. When the database is quiet, it collects credits. When a busy moment arrives, it spends them to run faster. If the credits run out, the server slows to its baseline. That is why Burstable is excellent for test systems and unpredictable light loads, but a poor choice for a database that is busy all day.

Memory is the secret to speed

Databases are fastest when the data they use often can be kept in memory. This memory area is called the buffer cache or buffer pool. If the most-used data fits in memory, queries return quickly without waiting for the disk. When the working set grows larger than memory, the server reads from disk much more often and speed falls. This is why a server with more memory per vCore, the Memory Optimized tier, can help heavy workloads more than adding more CPU.

Storage

Data and logs are kept on managed Premium SSD storage. You choose the size, and you can increase it later, but you cannot shrink it. Optional storage auto-grow can enlarge the storage automatically as it fills, which protects you from the nightmare of a database stopping because the disk is full. The storage size also sets the baseline IOPS, so a bigger disk gives you more speed. Some setups also let you pay for extra IOPS on their own, separate from size.

How to size a new server

Let us follow one small change, saving a new order, from the application to safe storage.

sequenceDiagram
    participant App as Application
    participant Eng as Database Engine
    participant Log as Transaction Log
    participant Stb as Standby Server
    participant Dsk as Data Files on Disk
    App->>Eng: Save a new order and commit
    Eng->>Eng: Change the page in memory
    Eng->>Log: Write the change to the log
    Log->>Stb: Ship the log record to the standby
    Stb-->>Log: Confirm the log is safe
    Log-->>Eng: The log is durable
    Eng-->>App: Commit succeeded
    Eng->>Dsk: Write changed pages later in the background
    

Step by step

PostgreSQL: versions and vacuum

PostgreSQL uses a design called multi-version concurrency control. When a row is changed, it does not overwrite the old row. It writes a new version and keeps the old one until no running transaction needs it. This lets many people read and write at the same time without blocking each other. The old versions, called dead rows, must be cleaned up. A background process named autovacuum does this cleaning. If it falls behind, tables grow with wasted space, called bloat, and queries slow down. In very long-running systems, a cleanup task also protects against a rare but serious problem called transaction ID wraparound. Watching autovacuum is a basic part of caring for PostgreSQL.

MySQL: InnoDB, redo logs, and binary logs

MySQL’s standard storage engine is called InnoDB. It keeps a redo log to guarantee that committed changes survive a crash, and undo logs to roll back unfinished work and to show readers older versions of rows. Separately, the binary log records every change in order, and this log is what feeds read replicas and point-in-time restore. The memory area that caches data is called the InnoDB buffer pool, and sizing it well is the main tuning lever for speed.

Checkpoints and recovery

Both engines periodically make sure that enough changed pages have been written to disk, so that crash recovery has only a small amount of log to replay. If you ever see a short pause or a burst of disk activity at regular intervals, a checkpoint is often the cause. Azure sets sensible defaults, but heavy write workloads may benefit from tuning.

Many database problems are not about the database at all. They are about how applications connect to it.

What a connection costs

A connection is an open conversation between an application and the database. In PostgreSQL, each connection is served by its own operating system process, which uses a noticeable amount of memory. In MySQL, each connection uses a thread with smaller, but still real, memory use. Both engines have a maximum number of connections, which depends on the size of the server. If too many applications or too many copies of one application open connections, the server can run out of memory or hit the limit, and new connections are refused.

Connection pooling

A connection pool keeps a modest number of open connections ready and lends them to the application when needed. This avoids the cost of opening a new connection for every request, and it keeps the total number of connections safely below the limit. Azure Database for PostgreSQL has a built-in pooler called PgBouncer that you can switch on and reach on its own port. For MySQL there is no built-in pooler, so applications use their own libraries’ pools or a proxy placed in front of the server.

Good habits for applications

• Reuse connections. Open them once and keep them, rather than opening and closing for each request.
• Limit pool sizes so that the total across all application instances stays below the server’s maximum.
• Retry on failure. During a failover, maintenance restart, or scaling event, connections drop for a short time. Applications should reconnect automatically after a brief wait.
• Set sensible timeouts so a stuck request does not hold a connection forever.
• Close transactions quickly. A transaction left open and idle holds resources and, in PostgreSQL, stops cleanup.
• Use encrypted connections, which Azure enforces by default.

The server name stays the same

When a failover happens, the standby becomes the primary, but the server’s name does not change. The same name now points to the new primary. This is why applications should connect by name, never by a remembered address, and why reconnecting is usually all they need to do.

Scaling out applications multiplies connections

A common surprise is that adding more application servers, or autoscaling a web tier from five instances to fifty, multiplies the number of database connections by ten. A database that was perfectly happy can suddenly fail because it is flooded with connections. Plan connection totals together with application scaling, and put a pooler in the middle where possible.

A database holds your most valuable data, so deciding who can reach it is one of the first and most important choices you make.

Two ways to be reachable

How private access works

With private access, you set aside a subnet and delegate it to the database service, which tells Azure that only this service may place servers there. Your applications in the same virtual network, or in networks connected to it through peering, a VPN, or ExpressRoute, reach the database through its private name. A private DNS zone makes sure the server’s name resolves to the right private address. Azure also offers private endpoints for some situations, which give the server a private address inside a subnet of your choosing, so you can combine private connectivity with other layouts.

Choose carefully at creation

The basic network style of a server, public access or private access through a delegated subnet, is decided when you create the server, and switching between them later is limited or not possible. Plan this with your network team before you build. Moving a database from one style to another usually means creating a new server and migrating the data.

Encrypted connections

Azure requires encrypted connections by default, using TLS with modern versions. Your applications should be configured to use encryption and to verify the server’s certificate. This protects passwords and data on their journey, even inside a private network.

A database server has a life story: planning, creation, daily work, change, and retirement. Knowing the steps prevents surprises.

flowchart LR
    A["Plan: engine, version, region, size"] --> B["Create the server"] --> C["Set up network and security"] --> D["Create databases and users"] --> E["Applications connect and work"]
    E --> F["Automated backups and monitoring"] --> E
    E --> G["Scale compute or storage"] --> E
    E --> H["Add read replicas"] --> E
    E --> I["Minor patches in maintenance windows"] --> E
    E --> J["Major version upgrade"] --> E
    E --> K["Stop, restore, or delete"]
    

Planning

Before creating anything, decide the engine, the major version, the region, the network style, the size, the availability level, and the backup settings. Choose a region close to your application servers, because distance adds delay to every query. Choose the version carefully: a newer major version gives more features and a longer support life, while an older version may be needed for application compatibility.

Creation and setup

Daily work and change

Once running, the server serves queries, takes backups, and sends metrics to Azure Monitor. Over time you will adjust parameters, add indexes, scale the compute size, add read replicas, and accept monthly maintenance. Most of these actions can be done while the server stays online, though some, such as changing compute size or certain parameters, cause a short restart.

Retirement

When a server is no longer needed, you delete it. This is serious: the automatic backups of a deleted server are removed along with it, so you cannot restore it afterward. Before deleting anything important, take an export of the data or a copy you can keep, and confirm that nothing still depends on it.

Machines fail, buildings lose power, and software needs updating. High availability is how your database keeps answering through all of it.

Failure comes in layers

Zone-redundant and same-zone high availability

When you turn on high availability, Azure creates a standby server that continuously receives every change from the primary. With zone-redundant high availability, the standby sits in a different availability zone, so even the loss of a whole building does not stop your database. With same-zone high availability, the standby is in the same zone, which protects against server failures but not zone failures, and is useful in regions without zones. The standby is not for queries. It waits.

What a failover looks like

A typical failover takes roughly one to two minutes, though this depends on the workload and how much recovery work remains. Applications that retry their connections recover on their own. Applications that crash on the first error need a human to restart them. You can also trigger a planned failover yourself to test your application, which is a good habit before going to production.

Availability promise

Microsoft publishes a service level agreement for these services, with the highest availability offered for servers with zone-redundant high availability, and lower figures for servers without it. These numbers cover the service itself, not your application or network. Read the current agreement for exact terms before quoting it in a contract.

Maintenance

Azure regularly patches the operating system and applies minor engine updates, usually once a month. You can choose a custom maintenance window, such as Sunday at three in the morning, so that disruption lands in a quiet period. With high availability on, Azure updates the standby first, then switches over, so the interruption is short. Major version upgrades are different: they move to a new engine version with new features and removed old behavior, and you start them yourself after testing. Never upgrade production without a trial on a restored copy.

A good backup plan is the difference between a bad afternoon and the loss of a business. The service handles the mechanics, but you decide the rules.

How automatic backups work

Azure takes regular backups of the server’s data and continuously archives the transaction log. A backup alone shows the data as it was at one moment. The archived log lets Azure replay changes forward from that moment. Together they allow point-in-time restore: you pick any second within your retention period, and Azure builds the database as it was at that second.

Retention and redundancy

• Retention period. You can keep point-in-time history for seven to thirty-five days. A longer period gives more time to discover a mistake, and costs more backup storage over the free allowance.
• Backup redundancy. Backups can be stored in one location, across availability zones, or copied to another region with geo-redundancy. Geo-redundant backups are usually chosen when the server is created, so decide early.
• Long-term retention. For audit rules that need monthly or yearly copies for years, check the current long-term backup options for your engine, or schedule your own exports into storage.

Restoring creates a new server

A restore never overwrites your existing server. It creates a brand-new server from the chosen moment. You can then check the data, copy back what you need, or switch the application to the new server. Remember that a restored server needs its network settings, firewall rules, alerts, and permissions set up again, because these live in the resource, not in the backup. Practice a restore, time it, and write down the steps before you ever need them.

Disaster recovery across regions

If a whole region is lost, zone-redundant high availability cannot help, because all the zones are in that region. You have two main choices. A cross-region read replica keeps a continuously updated copy in another region; in a disaster you promote it to become an independent writable server. Geo-restore uses geo-redundant backups to rebuild the server in another region. The replica gives a much shorter recovery time and less data loss, while geo-restore costs less and is slower.

Two numbers every plan needs

The recovery point objective is how much recent data you can afford to lose. The recovery time objective is how long you can afford to be down. Write both down for each database. A shop’s product catalogue may tolerate an hour of loss, while a payment ledger may tolerate none. These two numbers decide which of the tools above you need.

When one server is no longer enough, you can make it stronger, or you can share its work. Each approach has its place.

Scaling up: a bigger server

Vertical scaling means moving to a larger compute size, with more vCores and memory. It is the simplest fix, because the application does not change. Changing compute size restarts the server, so the database is briefly unavailable. Storage can also be increased, but not decreased. There is a ceiling to how large a single server can be, and the largest sizes cost a great deal, so scaling up is not a forever answer.

Scaling out reads: read replicas

Many applications read far more than they write. A read replica is an additional server that receives all changes from the primary and answers read-only queries. PostgreSQL supports up to five replicas and MySQL supports up to ten. Replication to replicas is asynchronous, which means a replica can be a little behind the primary. This delay is called replica lag.

Using replicas wisely

• Send reporting and search queries to replicas so heavy reads do not slow the main system.
• Route reads in the application or through a proxy. The database does not choose for you.
• Expect lag. Do not read a replica right after writing and expect to see the change. For such cases, read from the primary.
• Watch the lag metric and alert if it grows, because a replica far behind is serving old data.
• Remember cost. Each replica is a full server with its own compute and storage charges.
• Use cross-region replicas for disaster recovery as well as for bringing reads closer to distant users.

Promoting a replica

A replica can be promoted to a standalone server. This stops replication and makes the server writable. The step is one-way: the promoted server does not rejoin as a replica. It is used in disasters and in planned moves, such as migrating to a new region.

Other ways to relieve the database

When one server is truly not enough

A few systems outgrow the largest single server for writes. Options include splitting data across several databases by customer or region in your own application, or using a distributed database product designed for that purpose. These choices add complexity, so exhaust simpler options first.

Databases hold customer records, orders, and secrets. Azure offers layers of protection, and the best designs use several of them together.

Layer one: the network

Keep the server off the open internet with private access, or with a strict firewall if you must use public access. Allow only the application subnets and administrator addresses that truly need to connect.

Layer two: encrypted connections

All connections use TLS encryption by default, which stops eavesdroppers from reading passwords or data in transit. Keep this requirement on, and have applications verify the server’s certificate.

Layer three: encryption at rest

Data files, backups, and logs are encrypted on disk automatically with strong encryption and keys that Microsoft manages. If your rules require control of the keys, you can use customer-managed keys stored in Azure Key Vault. Then you decide when keys rotate and who may use them, but you also carry the duty to protect them, since a lost key means unreadable data.

Layer four: who is allowed to sign in

• Database users and passwords are the classic method. Use strong, unique passwords and a separate user for each application.
• Microsoft Entra ID authentication lets people and applications sign in with their organization identity, using short-lived tokens instead of stored passwords. Applications running in Azure can use managed identities, so no password is written in any configuration file.
• Least privilege. Give each user only the rights it needs. An application that reads data should not be able to drop tables.

Layer five: watching and recording

Turn on audit logging so you know who ran which statements. In PostgreSQL the pgAudit extension records detailed activity, and in MySQL the audit log feature does a similar job. Send the logs to Log Analytics for search and alerts. Microsoft Defender for Cloud offers protection for open-source relational databases, which can flag suspicious sign-in patterns and risky settings.

Protecting the management plane

Use Azure role-based access control so that only a few trusted people can delete servers or change security settings. Add resource locks on important servers. Use Azure Policy to require private networking, backups, and encryption settings across all your databases.

Protecting secrets

Never keep passwords inside application code or images. Store them in Azure Key Vault, or avoid them altogether with managed identities and Entra ID sign-in. Rotate passwords on a schedule, and remove access promptly when people leave a team.

A slow database makes the whole application feel slow. Good measurements tell you where to look before users start complaining.

Key metrics to watch

Logs that explain why

Metrics tell you that something is wrong. Logs help you learn why. Enable the slow query log, which records statements that take longer than a threshold you choose. In PostgreSQL, the pg_stat_statements extension collects statistics for every kind of query, such as how often each runs and how long it takes in total. Send logs to Log Analytics so you can search and graph them, and keep them long enough to compare this week with last month.

A calm method for slow queries

Common tuning wins

• Add the right indexes on columns used for filtering, joining, and sorting.
• Avoid asking for everything. Select only the columns you need and limit the number of rows.
• Avoid the “N plus one” pattern, where an application sends one query to get a list and then one more query for each item in the list. Fetch related data in one request instead.
• Batch writes instead of sending thousands of tiny single-row writes.
• Keep statistics fresh so the engine’s planner makes good choices.
• In PostgreSQL, watch autovacuum and fix long-running idle transactions that block cleanup.

Alerts that matter

Set alerts for high CPU over several minutes, storage nearing full, connections near the limit, replication lag, failed backups, and unusual numbers of failed sign-ins. Send them to the people who can act, and attach a short runbook that says what to check first.

Databases are often among the largest items in a cloud bill. A little care brings large savings.

How you are billed

You pay for compute by the hour, based on the tier and number of vCores. You pay for provisioned storage by the gigabyte each month, whether or not it is full. Backup storage beyond the free allowance, which is tied to your provisioned storage size, is billed separately. Extra provisioned IOPS, network data leaving Azure, and each read replica add their own charges. High availability roughly doubles the compute and storage cost, because a second server runs alongside the first.

Common sources of waste

Azure offers many ways to store data. These managed open-source services are the right choice for some jobs and the wrong choice for others.

Managed service versus a database on a virtual machine

Installing PostgreSQL or MySQL on a virtual machine gives you total control. You choose every setting, every extension, and every patch time. In return, you take on every task described earlier: backups, failover, security patches, and monitoring. A managed service restricts a few things, such as access to the operating system and some rarely used extensions, and gives back a large amount of free time and reliability. Most teams are better off with the managed service unless they have a specific need that it cannot meet.

Relational or NoSQL?

Relational databases like PostgreSQL and MySQL suit data with clear structure and relationships, such as customers, orders, and invoices, where correctness matters. NoSQL databases like Cosmos DB suit data with flexible shapes and extreme scale or global distribution needs. PostgreSQL’s strong JSON support also lets it handle semi-structured data well, so you can mix both styles in one system for many applications.

A simple way to decide

• Application built for MySQL or a MySQL-based platform: Azure Database for MySQL.
• New application with rich queries, maps, or AI search: Azure Database for PostgreSQL.
• Application built for SQL Server: Azure SQL.
• Massive global scale with simple access patterns: Cosmos DB.
• Need unusual control: a database on virtual machines, with your own operations team.

Patterns are recipes that have worked for many teams. Anti-patterns are recipes that look fine until the day they fail.

Patterns worth copying

Anti-patterns to avoid

A short list of habits prevents most database problems. A short list of mistakes causes most of them.

Best practices checklist

• Choose the engine and version on purpose, and plan upgrades before a version reaches the end of its support life.
• Use private networking for production, with a delegated subnet and private DNS.
• Turn on zone-redundant high availability for important databases and test a failover before launch.
• Set backup retention to match your needs, choose redundancy that fits, and practice point-in-time restores.
• Use connection pooling and keep total connections within limits.
• Build retry logic into every application that talks to the database.
• Sign in with Entra ID and managed identities where possible, and give each application the least privilege it needs.
• Enable auditing and send logs to Log Analytics, and use Defender for Cloud for threat detection.
• Monitor the key numbers and alert on CPU, storage, connections, replica lag, and backup failures.
• Tune queries first, then add caching, replicas, and bigger sizes in that order.
• Schedule maintenance in a quiet window and read the notifications that Azure sends in advance.
• Describe servers and schema changes as code, reviewed and repeatable.
• Tag, budget, and review every server on a regular schedule.

Mistakes beginners make

PostgreSQL and MySQL sit underneath a huge share of the web. Here are the kinds of systems where these managed services shine.

Common workloads

Company scenarios

The scenarios below describe typical situations rather than named companies, because real designs are private. They show how teams combine the ideas of this guide.

Most teams do not start from nothing. They move an existing database from their own servers, another cloud, or an older Azure service. A calm plan keeps this safe.

Two broad styles

Tools you can use

• Native tools such as the standard dump and restore utilities of each engine.
• The migration service in the Azure portal for supported sources, which can do offline and online moves and guides you through checks.
• Azure Database Migration Service for broader and larger projects.
• Logical replication in PostgreSQL and binary log replication in MySQL for near-zero-downtime moves, when the source and target support it.

Tool names and capabilities change, so confirm the current options in the Azure documentation before you decide.

A calm migration plan

Moving from the retired Single Server

The older Single Server deployment style has been retired for both engines. If you still have databases or documents that refer to it, move them to Flexible Server using the migration tools and guidance Microsoft provides, and take the chance to review network, backup, and security settings, which are different in the newer model.

When something goes wrong, a calm, ordered checklist beats panic every time.

A calm method for a slow database

Short, direct answers to the questions beginners ask most.

You began with a shop owner who hired a record-keeping firm. You now know how Azure plays that role for your application’s data.

Azure Database for PostgreSQL and Azure Database for MySQL are managed services that run the real open-source engines on Flexible Server. Azure handles the machines, patches, backups, and failovers, while you design the data, the queries, and the access rules. With good choices about engine, size, network, availability, security, and monitoring, they give you a database that is fast, safe, and affordable, and that your team can run with confidence.