Azure Database for MySQL Blog articles

Tutorial: Building AI Agents That Talk to Your Azure Database for MySQL

FarahAbdou — Wed, 15 Apr 2026 13:00:00 GMT

What if you could ask your database a question in plain English and get the answer instantly, without writing a single line of SQL?

In this tutorial, you'll build a Python-based AI agent that connects to Azure Database for MySQL server and uses OpenAI's function calling to translate natural language questions into SQL queries, execute them, and return human-readable answers. The agent can explore your schema, answer business questions, and even self-correct when it writes invalid SQL.

What you'll build:

An Azure Database for MySQL server with sample data
A Python AI agent with three tools: list_tables, describe_table, and run_sql_query
- In the context of AI agents, tools are functions the agent can call to interact with external systems like querying a database, fetching a file, or calling an API. Here, our agent has three tools that let it explore and query your MySQL database.
An interactive chat interface where you ask questions and the agent auto-generates and runs SQL

Prerequisites

Before you begin, make sure you have:

An Azure account — Sign up for free (includes 12 months of free MySQL hosting)
An OpenAI API key — Get one here (you'll need a few dollars of credit)
Python 3.10+ — Download here (check "Add to PATH" during install)
A code editor — VS Code recommended
Optional: You can download the complete project from this GitHub repository, or follow the step‑by‑step instructions below to build it from scratch.

Step 1 — Create the Azure Database for MySQL server

Go to the Azure Portal
Search for "Azure Database for MySQL server" and click + Create
Configure the following settings:

Setting	Value
Resource group	rg-mysql-ai-agent (create new)
Server name	mysql-ai-agent (or any unique name)
Region	Your nearest region
MySQL version	8.4
Workload type	Dev/Test (Burstable B1ms — free for 12 months)
Admin username	mysqladmin
Password	A strong password — save it!

4. ✅ Check "Add firewall rule for current IP address"

⚠️ Important: If you skip the firewall settings, you won't be able to connect from Cloud Shell or your local machine.

5. Click Review + create → Create and wait 3–5 minutes

Once deployment finishes, navigate to your server and note the hostname from the Connection details:

mysql-ai-agent.mysql.database.azure.com

Step 2 — Load Sample Data

Open Azure Cloud Shell by clicking the >_ icon in the portal's top toolbar. Select Bash if prompted.

Connect to your MySQL server. You can copy the exact connection command from the "Connect from browser or locally" section on your server's overview page in the Azure portal:

mysql -h mysql-ai-agent.mysql.database.azure.com -u mysqladmin -p

Enter your password when prompted (the cursor won't move — just type and press Enter).

Now paste the following SQL to create a sample sales database:

CREATE DATABASE demo_sales; USE demo_sales;

CREATE TABLE customers ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100), email VARCHAR(100), city VARCHAR(50), signup_date DATE ); CREATE TABLE orders ( id INT AUTO_INCREMENT PRIMARY KEY, customer_id INT, product VARCHAR(100), amount DECIMAL(10,2), order_date DATE, FOREIGN KEY (customer_id) REFERENCES customers(id) ); INSERT INTO customers (name, email, city, signup_date) VALUES ('Sara Ahmed', 'sara@example.com', 'Cairo', '2024-06-15'), ('John Smith', 'john@example.com', 'London', '2024-08-22'), ('Priya Patel', 'priya@example.com', 'Mumbai', '2025-01-10'); INSERT INTO orders (customer_id, product, amount, order_date) VALUES (1, 'Azure Certification Voucher', 150.00, '2025-03-01'), (2, 'MySQL Workbench Pro License', 99.00, '2025-03-10'), (1, 'Power BI Dashboard Template', 45.00, '2025-04-05'), (3, 'Data Analysis Course', 200.00, '2025-05-20');

Verify the data:

SELECT * FROM customers; SELECT * FROM orders;

Type exit to leave MySQL.

Step 3 — Set Up the Python Project

Open a terminal on your local machine and create the project:

mkdir mysql-ai-agent cd mysql-ai-agent python -m venv venv

Activate the virtual environment:

Windows (PowerShell):

venv\Scripts\Activate.ps1

macOS/Linux:

source venv/bin/activate

Install the required packages:

pip install openai mysql-connector-python python-dotenv

Step 4 — Configure Environment Variables

Create a file named .env in your project folder:

OPENAI_API_KEY=sk-proj-xxxxxxxxxxxxxxxxxxxxxxxx MYSQL_HOST=mysql-ai-agent.mysql.database.azure.com MYSQL_USER=mysqladmin MYSQL_PASSWORD=YourPasswordHere MYSQL_DATABASE=demo_sales

🔒 Security: Never commit this file to Git. Add .env to your .gitignore

Step 5 — Build the Agent

Open VS Code, create a new file called mysql_agent.py in your mysql-ai-agent folder, and paste the following code. Let's walk through each section.

5.1 — Imports and Database Connection

import os import json import mysql.connector from openai import OpenAI from dotenv import load_dotenv load_dotenv() def get_db_connection(): return mysql.connector.connect( host=os.getenv("MYSQL_HOST"), user=os.getenv("MYSQL_USER"), password=os.getenv("MYSQL_PASSWORD"), database=os.getenv("MYSQL_DATABASE"), ssl_disabled=False )

This loads your secrets from .env and creates a reusable MySQL connection function with SSL encryption.

5.2 — Define the Three Tools

These are the functions the AI agent can call:

def list_tables(): conn = get_db_connection() cursor = conn.cursor() cursor.execute("SHOW TABLES") tables = [row[0] for row in cursor.fetchall()] cursor.close() conn.close() return json.dumps({"tables": tables}) def describe_table(table_name): conn = get_db_connection() cursor = conn.cursor() cursor.execute(f"DESCRIBE `{table_name}`") columns = [] for row in cursor.fetchall(): columns.append({ "field": row[0], "type": row[1], "null": row[2], "key": row[3] }) cursor.close() conn.close() return json.dumps({"table": table_name, "columns": columns}) def run_sql_query(query): if not query.strip().upper().startswith("SELECT"): return json.dumps({"error": "Only SELECT queries are allowed."}) conn = get_db_connection() cursor = conn.cursor() try: cursor.execute(query) columns = [desc[0] for desc in cursor.description] rows = cursor.fetchall() results = [] for row in rows: results.append(dict(zip(columns, row))) return json.dumps({"columns": columns, "rows": results}, default=str) except mysql.connector.Error as e: return json.dumps({"error": str(e)}) finally: cursor.close() conn.close()

A few things to note:

run_sql_query only allows SELECT statements — this is a safety guardrail that prevents the AI from modifying data
The try/except block is critical — if the AI generates invalid SQL (e.g., a bad GROUP BY), the error message is returned to OpenAI, and the model automatically corrects its query and retries. Without this, the script would crash.

5.3 — Register Tools with OpenAI

This tells OpenAI what tools the agent has access to:

tools = [ { "type": "function", "function": { "name": "list_tables", "description": "List all tables in the connected MySQL database.", "parameters": {"type": "object", "properties": {}, "required": []} } }, { "type": "function", "function": { "name": "describe_table", "description": "Get the schema (columns and types) of a specific table.", "parameters": { "type": "object", "properties": { "table_name": {"type": "string", "description": "Name of the table to describe"} }, "required": ["table_name"] } } }, { "type": "function", "function": { "name": "run_sql_query", "description": "Execute a read-only SQL SELECT query and return results.", "parameters": { "type": "object", "properties": { "query": {"type": "string", "description": "The SQL SELECT query to execute"} }, "required": ["query"] } } } ] def call_tool(name, args): if name == "list_tables": return list_tables() elif name == "describe_table": return describe_table(args["table_name"]) elif name == "run_sql_query": return run_sql_query(args["query"]) else: return json.dumps({"error": f"Unknown tool: {name}"})

5.4 — The Agent Loop

This is the core logic. It sends the user's message to OpenAI, processes any tool calls, and loops until the model produces a final text response:

def chat(user_message, conversation_history): client = OpenAI() conversation_history.append({"role": "user", "content": user_message}) print(f"\n{'='*60}") print(f"🧑 You: {user_message}") print(f"{'='*60}") while True: response = client.chat.completions.create( model="gpt-4o-mini", messages=conversation_history, tools=tools, tool_choice="auto" ) assistant_message = response.choices[0].message if assistant_message.tool_calls: conversation_history.append(assistant_message) for tool_call in assistant_message.tool_calls: fn_name = tool_call.function.name fn_args = json.loads(tool_call.function.arguments) print(f" 🔧 Calling tool: {fn_name}({json.dumps(fn_args)})") result = call_tool(fn_name, fn_args) print(f" ✅ Tool returned: {result[:200]}...") conversation_history.append({ "role": "tool", "tool_call_id": tool_call.id, "content": result }) else: final_answer = assistant_message.content conversation_history.append({"role": "assistant", "content": final_answer}) print(f"\n🤖 Agent:\n{final_answer}") return conversation_history

The while True loop is what makes self-correction possible. When a tool returns an error, the model sees it in the conversation and generates a corrected tool call in the next iteration.

5.5 — Main Entry Point

if __name__ == "__main__": print("\n" + "=" * 60) print(" 🤖 MySQL AI Agent") print(" Powered by OpenAI + Azure Database for MySQL") print(" Type 'quit' to exit") print("=" * 60) system_message = { "role": "system", "content": ( "You are a helpful data analyst agent connected to an Azure Database for MySQL. " "You have 3 tools: list_tables, describe_table, and run_sql_query. " "ALWAYS start by listing tables and describing their schema before writing queries. " "Only generate SELECT statements. Never write INSERT, UPDATE, DELETE, or DROP. " "Present query results in clean, readable tables. " "If the user asks a question, figure out the right SQL to answer it." ) } conversation_history = [system_message] while True: user_input = input("\n🧑 You: ").strip() if user_input.lower() in ("quit", "exit", "q"): print("\n👋 Goodbye!") break if not user_input: continue conversation_history = chat(user_input, conversation_history)

Your final project folder should look like this:

Step 6 — Run and Test the Agent

python mysql_agent.py

Test:

Prompt: Which product generated the most revenue and who bought it?

How Self-Correction Works

One of the most powerful aspects of this agent is its ability to recover from SQL errors automatically. Azure Database for MySQL has sql_mode=only_full_group_by enabled by default, which rejects queries where non-aggregated columns aren't in the GROUP BY clause.

When the AI generates an invalid query, here's what happens:

The run_sql_query function catches the MySQL error
It returns the error message as the tool result
OpenAI sees the error in the conversation context
The model generates a corrected query automatically
The agent retries — and succeeds

Without the try/except error handling, the entire script would crash. This is a key design pattern for production AI agents.

Security Best Practices

When building AI agents that interact with databases, security is critical:

Read-only enforcement — The run_sql_query function rejects anything that isn't a SELECT statement
SSL encryption — All connections use ssl_disabled=False, ensuring data in transit is encrypted
Environment variables — Credentials are stored in .env, never hardcoded
Principle of least privilege — For production, create a dedicated MySQL user with SELECT-only permissions:

CREATE USER 'ai_agent'@'%' IDENTIFIED BY 'AgentPass123!'; GRANT SELECT ON demo_sales.* TO 'ai_agent'@'%'; FLUSH PRIVILEGES;

Network isolation — For production workloads, consider using Azure Private Link instead of public access.

Conclusion

In this tutorial, you built a Python AI agent that connects to Azure Database for MySQL and answers natural language questions by auto-generating SQL - complete with self-correction and security guardrails. Clone the GitHub repo, spin up your own server, and start experimenting!

If you'd like to connect to Azure Database for MySQL using the Model Context Protocol (MCP), see Unlocking AI-Driven Data Access: Azure Database for MySQL Support via the Azure MCP Server.

If you have any feedback or questions about the information provided above, please leave a comment below. Thank you!

Announcing Fabric Mirroring integration for Azure Database for MySQL - Public Preview at FabCon 2026

Vandhana_Mehta — Thu, 02 Apr 2026 04:43:02 GMT

At FabCon 2026, we’re excited to announce the Public Preview of Microsoft Fabric Mirroring integration for Azure Database for MySQL. This integration makes it easier than ever to analyze MySQL operational data using Fabric’s unified analytics platform, without building or maintaining ETL pipelines.

This milestone brings near real-time data replication from Azure Database for MySQL into Microsoft Fabric OneLake, unlocking powerful analytics, reporting, and AI scenarios while keeping transactional workloads isolated and performant.

Why Fabric integration for Azure Database for MySQL?

MySQL is widely used to power business‑critical applications, but operational databases aren’t optimized for analytics. Traditionally, teams rely on complex ETL pipelines, custom connectors, or batch exports — adding cost, latency, and operational overhead. With Fabric integration, Azure Database for MySQL now connects directly to Microsoft Fabric, enabling:

Zero‑ETL analytics on MySQL operational data
Near real-time synchronization into OneLake
Analytics‑ready open formats for BI, data engineering, and AI
A unified experience across Power BI, Lakehouse, Warehousing, and notebooks

All without impacting your production workloads.

What’s new in the Public Preview?

The Public Preview introduces a first‑class integration between Azure Database for MySQL and Microsoft Fabric, designed for simplicity and scale. It introduces a solid set of core operational and enterprise‑readiness capabilities, enabling end-users to confidently get started and scale their analytics scenarios.

Core replication operations
- Start, monitor, and stop replication directly from the integrated experience
- Support for both initial data load and continuous change data capture (CDC) to keep data in sync with minimal latency.
Network and security
- Firewall and gateway support, enabling replication from secured MySQL environments.
- Support for Azure Database for MySQL servers configured with customer‑managed keys (BYOK), aligning with enterprise security and compliance requirements.
Broader data coverage and troubleshooting
- Ability to mirror tables containing previously unsupported data types, expanding schema compatibility and reducing onboarding friction.
- Support for up to 1,000 tables per server, enabling larger and more complex databases to participate in Fabric analytics.
- Basic error messaging and visibility to help identify replication issues and monitor progress during setup and ongoing operations.

What scenarios does it unlock?

With Fabric integration in place, you can now analyze data in Azure Database for MySQL without impacting production, combine it with other data in Fabric for richer reporting, and use Fabric’s built‑in analytics and AI tools to get insights faster. Learn more about exploring replicated data in Fabric in Explore data in your mirrored database using Microsoft Fabric.

How does it work (high level)?

Fabric integration for Azure Database for MySQL follows a simple but powerful pattern:

Enable and Configure - Enable replication in the Azure portal, then use the Fabric portal to provide connection details and select MySQL tables to mirror.
Initial snapshot - Fabric takes a bulk snapshot of the selected tables, converts the data to Parquet, and writes it to a Fabric landing zone.
Continuous change capture - Ongoing inserts, updates, and deletes are captured from MySQL binlogs and continuously written as incremental Parquet files.
Analytics‑ready in Fabric - The Fabric Replicator processes snapshot and change files and applies them to Delta tables in OneLake, keeping data in sync and ready for analytics.

This design ensures low overhead on the source, while providing fresh data for analytics and AI workloads.

Below is a more detailed workflow illustrating how this works:

Getting started with the Public Preview

To try Fabric integration for Azure Database for MySQL during Public Preview, you’ll need:

An Azure Database for MySQL instance
An active Microsoft Fabric capacity (trial or paid)
Access to a Fabric workspace

Once enabled, you can select the MySQL databases and tables you want to replicate and begin analyzing data in Fabric. For step-by-step tutorial, please refer to - https://learn.microsoft.com/azure/mysql/integration/fabric-mirroring-mysql

The demo video below showcases how the mirroring integration works and walks through the end-to-end experience of mirroring MySQL data into Microsoft Fabric.

Stay Connected

We’re thrilled to share this milestone at FabCon 2026 and can’t wait to see how you use Fabric integration for Azure Database for MySQL to simplify analytics and unlock new insights. We welcome your feedback and invite you to share your experiences or suggestions at AskAzureDBforMySQL@service.microsoft.com

Try the Public Preview, share your feedback, and help shape what’s next. Thank you for choosing Azure Database for MySQL!

February 2026 Recap: Azure Database for MySQL

SaurabhKirtani — Wed, 11 Mar 2026 13:00:00 GMT

We're excited to share a summary of the Azure Database for MySQL updates from the last couple of months.

Extended Support Timeline Update

Based on customer feedback requesting additional time to complete major version upgrades, we have extended the grace period before extended support billing begins for Azure Database for MySQL:

MySQL 5.7: Extended support billing start date moved from April 1, 2026 to August 1, 2026.
MySQL 8.0: Extended support billing start date moved from June 1, 2026 to January 1, 2027.

This update provides customers additional time to plan, validate, and complete upgrades while maintaining service continuity and security. We continue to recommend upgrading to a supported MySQL version as early as possible to avoid extended support charges and benefit from the latest improvements. Learn more about performing a major version upgrade in Azure Database for MySQL.

When upgrading using a read replica, you can optionally use the Rename Server feature to promote the replica and avoid application connection‑string updates after the upgrade completes. Rename Server is currently in Private Preview and is expected to enter Public Preview around the April 2026 timeframe.

Private Preview - Fabric Mirroring for Azure Database for MySQL

This capability enables real‑time replication of MySQL data into Microsoft Fabric with a zero‑ETL experience, allowing data to land directly in OneLake in analytics‑ready formats. Customers can seamlessly analyse mirrored data using Microsoft Fabric experiences, while isolating analytical workloads from their operational MySQL databases.

Stay Connected

We welcome your feedback and invite you to share your experiences or suggestions at AskAzureDBforMySQL@service.microsoft.com

Stay up to date by visiting What's new in Azure Database for MySQL, and follow us on YouTube | LinkedIn | X for ongoing updates.

Thank you for choosing Azure Database for MySQL!

Guide to Upgrade Azure Database for MySQL from 8.0 to 8.4

SamZhao — Thu, 05 Mar 2026 14:00:00 GMT

This guide merges Azure official documentation and best practices from real-world upgrades. Always refer to the latest Azure documentation and portal/CLI for any updates or discrepancies.

1. Background

Why Upgrade?

MySQL 5.7 reached end of community support in October 2023, and will enter extended support in August 2026.
MySQL 8.0 will reach end of community support in April 2026 and will enter extended support in January 2027.
MySQL 8.4 is the first official LTS (Long Term Support) version, officially supported by Oracle until April 2032.
Upgrading ensures security, performance, and continued support.

Supported Upgrade Paths:

5.7 → 8.0 (must be completed first)
8.0 → 8.4
Direct 5.7 → 8.4 is NOT supported.
Downgrades are NOT supported.

Key Notes:

Irreversible: Major version upgrades are irreversible and cannot be rolled back directly.
Downtime: The server is offline during the upgrade. Downtime depends on database size and table count.
HA Limitation: High Availability (HA) servers cannot achieve near-zero downtime during major upgrades due to cross-version replication instability.
Performance: Some workloads may not see performance improvements after upgrade.

2. Key Changes

Authentication Plugin Changes

mysql_native_password is disabled by default in the MySQL 8.4 community version. However, it is enabled by default in Azure MySQL 8.4. Older client versions may not be able to connect using mysql_native_password. If you encounter this issue, upgrade your client version first.
The default_authentication_plugin variable should be removed.
All users should be migrated to the caching_sha2_password plugin.

Foreign Key Constraint Enforcement

Before the upgrade, referenced columns must have a unique key; check all foreign key constraints before upgrade.

Removed Features

FLUSH HOSTS command → use TRUNCATE TABLE performance_schema.host_cache
PASSWORD() function → use ALTER USER
tx_isolation option → use transaction_isolation
expire_logs_days → use binlog_expire_logs_seconds
AUTO_INCREMENT is no longer allowed on FLOAT/DOUBLE columns

New Reserved Keywords

MANUAL, PARALLEL, QUALIFY, TABLESAMPLE — do not use these as unquoted identifiers

Terminology Changes

MASTER/SLAVE terminology updated to SOURCE/REPLICA
Update all scripts and applications using old the terms

InnoDB 8.0 → 8.4 Default Parameter Changes

innodb_adaptive_hash_index: ON → OFF
innodb_change_buffering: All → None
innodb_buffer_pool_in_core_file: ON → OFF
innodb_io_capacity: 200 → 10000
innodb_log_buffer_size: 16MB → 64MB

3. Upgrade Prerequisites

Basic Requirements

Item	Requirement
Deployment Type	Azure Database for MySQL Flexible Server instance only
Region	Region must support MySQL 8.4 in Azure Portal
Current Version	Must be 8.0.x (check via SELECT VERSION(); or Portal)
Server Status	Server must be running, with no ongoing scaling/restart/updates

Read Replica Version

If read replicas exist, upgrade them before upgrading the primary server. Cross-version replication is not guaranteed to be stable. Follow official documentation for handling replicas (stop replication and upgrade separately, or delete and recreate after upgrade).

Create On-Demand Backup

Before upgrading production, create an on-demand backup for rollback if needed: - Azure Portal > Your MySQL Server > Backup & Restore > Backup Now - Backups created before upgrade restore to the old version; backups after upgrade restore to the new version.

XA Transactions

Ensure no active or pending XA transactions:

XA RECOVER;

If any results are returned, roll back these transactions:

XA ROLLBACK 'xid';

SQL Mode

Remove deprecated sql_mode values before upgrade.

Deprecated: NO_AUTO_CREATE_USER, NO_FIELD_OPTIONS, NO_KEY_OPTIONS, NO_TABLE_OPTIONS - Check current SQL mode:

SELECT @@sql_mode;

In Azure Portal: Go to Server Parameters > Search “sql_mode” > Remove deprecated values > Save

4. Pre-Upgrade Checks

Use Upgrade Check Tool (MySQL Shell)

Check Items

The tool performs 40+ automated checks, mainly including:

Check Category	Description
Deprecated Time Types	Checks for old-format time columns
Reserved Keyword Conflicts	Checks for conflicts with reserved keywords in the new version
UTF8MB3 Charset	Checks for objects needing migration to UTF8MB4
Removed System Variables	Checks for configuration items no longer supported
Authentication Plugin Change	Checks for users needing updated authentication methods
Partition Table Restrictions	Checks for partition compatibility
Foreign Key Names	Checks for foreign key name conflicts

Oracle provides util.checkForServerUpgrade() to detect compatibility issues.

Install MySQL Shell 8.4 or higher.
Connect to Azure MySQL server:

mysqlsh --host=<your-server>.mysql.database.azure.com \ --user=<admin-user> \ --password \ --ssl-mode=REQUIRED

Run upgrade check:

util.checkForServerUpgrade() util.checkForServerUpgrade({"targetVersion": "8.4.0"})

Command-line (recommended):

mysqlsh <admin-user>@<your-server>.mysql.database.azure.com:3306 \ --ssl-mode=REQUIRED \ -- util checkForServerUpgrade \ --target-version=8.4.0 \ --output-format=JSON

Required privileges: RELOAD, PROCESS, SELECT.

The tool performs 40+ checks (deprecated types, reserved keywords, charset, removed variables, auth plugins, partitioning, FK constraints, etc.).

Review Results

Errors: Must be fixed before upgrade
Warnings: Strongly recommended to fix
Notices: Informational

Additional Compatibility and Validation Checks

Client Library Compatibility:

Some client libraries may be incompatible with MySQL 8.0+ due to outdated drivers. Collect and review all client driver versions and test compatibility in a staging environment before upgrade.

Authentication Changes

After upgrade, applications may fail to connect if not compatible with new authentication plugins. MySQL 8.0 defaults to caching_sha2_password, and MySQL 8.4 disables mysql_native_password by default.

Solution: Upgrade client drivers to versions supporting the new authentication method. If legacy drivers must be used, temporarily set user authentication to mysql_native_password and plan to upgrade drivers as soon as possible.

Charset and Collation Changes:

MySQL 8.0 defaults to utf8mb4 charset and utf8mb4_0900_ai_ci collation, which may cause changes in string comparison, index length limits, sort order, or JOIN-related errors due to charset mismatches.

Recommendations:

- Check if ORM and drivers support utf8mb4.
- Adjust index lengths (utf8mb4 uses up to 4 bytes per character).
- Specify COLLATE explicitly if you need to preserve original sort behavior.
- Standardize charset and collation settings for all tables and columns.

Object Statistics:

Review table and object statistics to estimate upgrade and rollback time.

Performance Considerations:

Most SQL workloads benefit from upgrades, but some queries may experience degraded performance (e.g., queries with ORDER BY, complex JOINs, subqueries, or many bound parameters). The optimizer evolves between versions (e.g., max_length_for_sort_data was deprecated in 8.0.20, execution plan changes, etc.).

Recommendations:

- Use standard SQL tuning methods: review execution plans, optimize queries, and add indexes as needed.

Test in Staging

💡 Strong Recommendation: First perform the upgrade in a staging environment (such as a restored backup copy of the original server) and validate the following:

Whether the upgrade process completes successfully
Estimated downtime
Application compatibility
Performance baseline comparison

5. Upgrade Methods & Scenarios

Upgrade Method Comparison

Method	Pros	Cons	Recommended For
In-Place Upgrade	Simple, no connection string change, no extra cost	Longer downtime, can be hours or even days, rollback only via backup	Dev/test, small prod, downtime allowed
Replica Based Upgrade	Low risk, fast rollback, minimal downtime	Extra cost, more steps, connection string change	Production, downtime sensitive

Method 1: In-Place Upgrade, Azure Portal (In-Place Upgrade, Recommended)

For General Purpose and Memory Optimized SKUs:

Sign in to Azure Portal
Navigate to your MySQL Flexible Server
Select Overview
Find MySQL Version and click Upgrade
Select target version 8.4
Review pre-upgrade validation
Confirm and start upgrade

For Burstable SKU: May require temporary SKU change to General Purpose before upgrade, then revert after.

Method 2: Azure CLI (In-Place Upgrade)

az cloud set --name AzureCloud az login az mysql flexible-server upgrade \ --name <your-server-name> \ --resource-group <your-resource-group> \ --version 8.4

Method 3: Minimal Downtime (Read Replica)

For production environments sensitive to downtime:

Create read replica (Portal > Replication > Add Replica)
Wait for replica sync (check SHOW REPLICA STATUS\G, ensure Seconds_Behind_Master = 0)
Upgrade replica to 8.4 (Portal or CLI)
Validate replica upgrade (SELECT VERSION();)
Promote replica to primary (Portal > Replication > Stop Replication)
Update application connection strings to new primary
(Optional) Delete old primary

This approach is an architecture migration + failover, not the same as in-place upgrade. Cross-version replication stability is not guaranteed. Fully test in staging and communicate risks to stakeholders.

6. Post-Upgrade Validation

Check MySQL version:

SELECT VERSION();

Check database and table status:

SHOW DATABASES; USE your_database; SHOW TABLE STATUS; CHECK TABLE your_table;

Validate application connectivity and key business functions
Monitor metrics for 24-48 hours: CPU, memory, I/O, query latency, error logs

7. Rollback Strategy

Major version upgrades are irreversible. Rollback requires restoring from backup:

Azure Portal > MySQL Server > Backup & Restore > Select pre-upgrade backup > Restore
Specify new server name
Wait for restore to complete
Update application connection strings to restored server

💡 The restored server is a new, independent server. The original server remains.

Business Rollback Advice:

- Confirm data loss/replay strategy for changes between upgrade and rollback
- Assess impact on dependent systems (reports, ETL, etc.)
- After rollback, point applications to old server, clean up new objects, and re-validate key functions

8. FAQs

Q1: Can I upgrade directly from MySQL 5.7 to 8.4?

No. Upgrade must be sequential: 5.7 → 8.0 → 8.4

Q2: How long does the upgrade take?

Downtime depends on database size, storage, and table count. Test in staging to estimate.

Q3: Can HA servers achieve zero downtime?

No. Major upgrades cannot use HA for near-zero downtime due to cross-version replication instability.

Q4: Will performance improve after upgrade?

Not guaranteed. Some workloads may see no change or slight decrease. Benchmark before and after.

Q5: Can I change other server properties during upgrade?

Not recommended. Avoid changing other properties via REST API or SDK during upgrade.

Q6: How to estimate downtime?

The number of objects contained in the database is related to the upgrade time; the larger the number, the longer it takes. The most accurate way to assess this is as follows. 1. Restore a test server from backup 2. Perform upgrade on test server 3. Record actual upgrade time 4. Add buffer for production

Q7: What happens to backups during/after upgrade?

Backups before upgrade restore to old version; after upgrade, to 8.4. Confirm retention and PITR settings before upgrade.

Q8: Is upgrade downtime included in SLA?

Planned downtime for upgrade is not counted in availability SLA. Schedule during maintenance window and communicate with stakeholders.

Q9: Charset and collation issues after upgrade?

MySQL 8.0+ defaults to utf8mb4 and utf8mb4_0900_ai_ci. Check ORM/driver support, adjust index length, specify COLLATE if needed, and unify charset settings.

Q10: Performance issues after upgrade?

Some queries may slow down due to optimizer changes. Use EXPLAIN/ANALYZE, add/optimize indexes, use query hints, and review execution plans.

Q11: Authentication issues after upgrade?

MySQL 8.0+ defaults to caching_sha2_password. Upgrade client drivers. If needed, temporarily revert user auth to mysql_native_password (not recommended for 8.4).

Q12: Client library compatibility?

Test all client libraries in staging. Upgrade outdated connectors/ORMs.

Q13: What is Azure Extended Support?

Azure provides paid extended support for MySQL versions after community EOL. See Extended Support for MySQL.

Stay Connected

We welcome your feedback and invite you to share your experiences or suggestions at AskAzureDBforMySQL@service.microsoft.com

Stay up to date by visiting What's new in Azure Database for MySQL, and follow us on YouTube | LinkedIn | X for ongoing updates.

Thank you for choosing Azure Database for MySQL!

References:

Now Generally Available: Azure Database for MySQL Triggers for Azure Functions

SaurabhKirtani — Mon, 29 Dec 2025 15:30:00 GMT

We’re thrilled to announce the general availability of Azure Database for MySQL Trigger bindings for Azure Functions!

This feature, previously in Public Preview, enables you to track changes and develop event-driven applications at scale on any MySQL table. This release completes the unified suite of Azure Database for MySQL bindings for Azure Functions, which now includes native support for Input, Output, and Trigger capabilities.

Overview

Trigger bindings enable you to automatically invoke Azure Functions when a row in a MySQL table is created or updated. This simplifies development by eliminating custom polling logic and the need to write and maintain boilerplate code.

How to get started?

Azure Database for MySQL trigger uses change tracking functionality to monitor a MySQL table for changes. You can set up change tracking by adding one column to the table. For example, enable it on the Products table using the following query:

ALTER TABLE Products; ADD az_func_updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;

The trigger bindings use az_func_updated_at and column data to monitor the user table for changes. Changes are then processed in the order that they were made, with the oldest changes being processed first.

For detailed, step-by-step guidance on using Azure Database for MySQL triggers with Azure Functions across all supported programming languages, visit our official documentation at https://aka.ms/mysqltriggers

Designed for scalable event-driven applications

With trigger bindings now Generally Available, you can unlock faster development cycles and smarter automation by reacting to MySQL data changes in real time without the complexity of custom polling or manual change tracking. This capability makes it easier than ever to build responsive, serverless solutions that scale effortlessly with your business needs. We look forward to seeing what you will build with them!

If you have any feedback or questions about the information provided above, please leave a comment below or email us at AskAzureDBforMySQL@service.microsoft.com. Thank you!

Announcing Azure Database for MySQL Support for Resource Move with Private Link

Elendil — Mon, 15 Dec 2025 14:19:35 GMT

Azure Database for MySQL now supports moving servers with Private Link enabled across subscriptions, resource groups, without disabling Private Link. In practical terms, this means you can relocate your MySQL server (for example, to a new subscription or resource group) while keeping its Private Endpoint intact and functional. This enhancement removes the previous requirement to delete and recreate Private Link connections during a move – a step that was necessary in the past and caused extra effort for customers. By eliminating that hurdle, the experience of reorganizing or migrating your MySQL resources is much simpler and less disruptive.

This capability delivers on Microsoft’s broader principle of full Azure resource mobility: features like Private Link should not impede standard management operations like moving resources. With this update, Azure Database for MySQL aligns with that vision, ensuring that network isolation and security (via Private Link) go hand-in-hand with flexibility in resource management.

What This Means for You

For Azure MySQL customers, the impact is significant: you gain the ability to reorganize and migrate your database servers more easily. Here are a few scenarios enabled by this new feature:

Cross-Subscription and RG Moves: If your organization reorganizes projects or if you maintain separate subscriptions (for example, one for development/staging and another for production), you can now move a MySQL server between those subscriptions or resource groups without interrupting its private network access. For instance, moving a server from a staging subscription to a production subscription is straightforward, with the Private Endpoint moving alongside the server.
No Downtime from Network Changes: Previously, moving a server with Private Link involved deleting the private endpoint, performing the move, and then re-creating the endpoint in the new location. This process could cause downtime or configuration churn. Now, the move is seamless – your database’s private IP connectivity remains in place throughout. There’s no need to update connection strings or firewall rules due to the move, which means less risk of error and no disruption to applications during resource transitions.

Aligned with Azure’s Mobility Principles

This feature is part of Azure’s continuous efforts to improve the manageability and flexibility of cloud services. Allowing resource moves for Private Link-enabled servers was an Azure-level commitment to our users, recognizing that enterprise workloads often evolve:

You might need to consolidate resources over time for easier management or billing.
You may have to transfer resources out of a subscription (for example, if a subscription is being retired or restructured).
You could be implementing disaster recovery or migration strategies that involve moving resources to new subscriptions or resource groups.

By ensuring Private Link does not constrain these scenarios, Azure Database for MySQL becomes more adaptable to your needs. You maintain strong network security without sacrificing agility.

Key Takeaway

With Azure Database for MySQL’s new support for Azure Resource Move with Private Link, you get the best of both worlds: the security of private network connectivity and the freedom to move your databases within Azure’s cloud environment. This update removes a pain point and streamlines operations, letting you focus on your applications rather than the underlying infrastructure logistics.

Moving forward, we remain committed to features that enhance your experience with Azure services. This improvement is now available in all Azure regions for Azure Database for MySQL. We encourage you to take advantage of the added flexibility as you plan your resource management and cloud architecture, and enjoy easier, uninterrupted moves for your Private Link-enabled databases.

Thank you for reading, and happy migrating!

Unlocking AI-Driven Data Access: Azure Database for MySQL Support via the Azure MCP Server

ramkumarchan — Mon, 08 Dec 2025 15:44:03 GMT

Step into a new era of data-driven intelligence with the fusion of Azure MCP Server and Azure Database for MySQL, where your MySQL data is no longer just stored, but instantly conversational, intelligent and action-ready. By harnessing the open-standard Model Context Protocol (MCP), your AI agents can now query, analyze and automate in natural language, accessing tables, surfacing insights and acting on your MySQL-driven business logic as easily as chatting with a colleague. It’s like giving your data a voice and your applications a brain, all within Azure’s trusted cloud platform.

We are excited to announce that we have added support for Azure Database for MySQL in Azure MCP Server. The Azure MCP Server leverages the Model Context Protocol (MCP) to allow AI agents to seamlessly interact with various Azure services to perform context-aware operations such as querying databases and managing cloud resources.

Building on this foundation, the Azure MCP Server now offers a set of tools that AI agents and apps can invoke to interact with Azure Database for MySQL - enabling them to list and query databases, retrieve schema details of tables, and access server configurations and parameters. These capabilities are delivered through the same standardized interface used for other Azure services, making it easier to the adopt the MCP standard for leveraging AI to work with your business data and operations across the Azure ecosystem.

Before we delve into these new tools and explore how to get started with them, let’s take a moment to refresh our understanding of MCP and the Azure MCP Server - what they are, how they work, and why they matter.

MCP architecture and key components

The Model Context Protocol (MCP) is an emerging open protocol designed to integrate AI models with external data sources and services in a scalable, standardized, and secure manner. MCP dictates a client-server architecture with four key components: MCP Host, MCP Client, MCP Server and external data sources, services and APIs that provide the data context required to enhance AI models. To explain briefly, an MCP Host (AI apps and agents) includes an MCP client component that connects to one or more MCP Servers. These servers are lightweight programs that securely interface with external data sources, services and APIs and exposes them to MCP clients in the form of standardized capabilities called tools, resources and prompts.

Learn more: MCP Documentation

What is Azure MCP Server?

Azure offers a multitude of cloud services that help developers build robust applications and AI solutions to address business needs. The Azure MCP Server aims to expose these powerful services for agentic usage, allowing AI systems to perform operations that are context-aware of your Azure resources and your business data within them, while ensuring adherence to the Model Context Protocol. It supports a wide range of Azure services and tools including Azure AI Search, Azure Cosmos DB, Azure Storage, Azure Monitor, Azure CLI and Developer CLI extensions. This means that you can empower AI agents, apps and tools to:

Explore your Azure resources, such as listing and retrieving details on your Azure subscriptions, resource groups, services, databases, and tables.
Search, query and analyze your data and logs.
Execute CLI and Azure Developer CLI commands directly, and more!

Learn more: Azure MCP Server GitHub Repository

Introducing new Azure MCP Server tools to interact with Azure Database for MySQL

The Azure MCP Server now includes the following tools that allow AI agents to interact with Azure Database for MySQL and your valuable business data residing in these servers, in accordance with the MCP standard:

Tool	Description	Example Prompts
azmcp_mysql_server_list	List all MySQL servers in a subscription & resource group	"List MySQL servers in resource group 'prod-rg'." "Show MySQL servers in region 'eastus'."
azmcp_mysql_server_config_get	Retrieve the configuration of a MySQL server	"What is the backup retention period for server 'my-mysql-server'?" "Show storage allocation for server 'my-mysql-server'."
azmcp_mysql_server_param_get	Retrieve a specific parameter of a MySQL server	"Is slow_query_log enabled on server my-mysql-server?" "Get innodb_buffer_pool_size for server my-mysql-server."
azmcp_mysql_server_param_set	Set a specific parameter of a MySQL server to a specific value	"Set max_connections to 500 on server my-mysql-server." "Set wait_timeout to 300 on server my-mysql-server."
azmcp_mysql_table_list	List all tables in a MySQL database	"List tables starting with 'tmp_' in database 'appdb'." "How many tables are in database 'analytics'?"
azmcp_mysql_table_schema_get	Get the schema of a specific table in a MySQL database	"Show indexes for table 'transactions' in database 'billing'." "What is the primary key for table 'users' in database 'auth'?"
azmcp_mysql_database_query	Executes a SELECT query on a MySQL Database. The query must start with SELECT and cannot contain any destructive SQL operations for security reasons.	“How many orders were placed in the last 30 days in the salesdb.orders table?” “Show the number of new users signed up in the last week in appdb.users grouped by day.”

These interactions are secured using Microsoft Entra authentication, which enables seamless, identity-based access to Azure Database for MySQL - eliminating the need for password storage and enhancing overall security.

How are these new tools in the Azure MCP Server different from the standalone MCP Server for Azure Database for MySQL? We have integrated the key capabilities of the Azure Database for MySQL MCP server into the Azure MCP Server, making it easier to connect your agentic apps not only to Azure Database for MySQL but also to other Azure services through one unified and secure interface!

How to get started

Installing and running the Azure MCP Server is quick and easy! Use GitHub Copilot in Visual Studio Code to gain meaningful insights from your business data in Azure Database for MySQL.

Pre-requisites

Install Visual Studio Code.
Install GitHub Copilot and GitHub Copilot Chat extensions.
An Azure Database for MySQL with Microsoft Entra authentication enabled. Ensure that the MCP Server is installed on a system with network connectivity and credentials to connect to Azure Database for MySQL.

Installation and Testing

Please use this guide for installation: Azure MCP Server Installation Guide

Try the following prompts with your Azure Database for MySQL: Azure Database for MySQL tools for Azure MCP Server

Try it out and share your feedback!

Start using Azure MCP Server with the MySQL tools today and let our cloud services become your AI agent’s most powerful ally.
We’re counting on your feedback - every comment, suggestion, or bug-report helps us build better tools together. Stay tuned: more features and capabilities are on the horizon!

Feel free to comment below or write to us with your feedback and queries at AskAzureDBforMySQL@service.microsoft.com.

Ignite 2025: Advancing Azure Database for MySQL with Powerful New Capabilities

DeepthiPrasad — Wed, 03 Dec 2025 07:17:11 GMT

At Ignite 2025, we’re introducing a wave of powerful new capabilities for Azure Database for MySQL, designed to help organizations modernize, scale, and innovate faster than ever before. From enhanced high availability and seamless serverless integrations to AI-powered insights and greater flexibility for developers, these advancements reflect our commitment to delivering a resilient, intelligent data platform. Join us as we unveil what’s next for MySQL on Azure - and discover how industry leaders are already building the future with confidence.

Enhanced Failover Performance with Dedicated SLB for High-Availability Servers

We’re excited to announce the General Availability of Dedicated Standard Load Balancer (SLB) for HA-enabled servers in Azure Database for MySQL. This enhancement introduces a dedicated SLB to High Availability configurations for servers created with public access or private link. By managing the MySQL data traffic path, SLB eliminates the need for DNS updates during failover, significantly reducing failover time.

Previously, failover relied on DNS changes, which caused delays due to DNS TTL (30 seconds) and client-side DNS caching.

What’s new with GA:

The FQDN consistently resolves to the SLB IP address before and after failover.

Load-balancing rules automatically route traffic to the active node.

Removes DNS cache dependency, delivering faster failovers.

Note: This feature is not supported for servers using private access with VNet integration.

Learn more

Build serverless, event-driven apps at scale – now GA with Trigger Bindings for Azure Functions

We’re excited to announce the General Availability of Azure Database for MySQL Trigger bindings for Azure Functions, completing the full suite of Input, Output, and Trigger capabilities. This feature lets you build real-time, event-driven applications by automatically invoking Azure Functions when MySQL table rows are created or updated - eliminating custom polling and boilerplate code.

With native support across multiple languages, developers can now deliver responsive, serverless solutions that scale effortlessly and accelerate innovation.

Learn more

Enable AI agents to query Azure Database for MySQL using Azure MCP Server

We’re excited to announce that Azure MCP Server now supports Azure Database for MySQL, enabling AI agents to query and manage MySQL data using natural language through the open Model Context Protocol (MCP). Instead of writing SQL, you can simply ask questions like “Show the number of new users signed up in the last week in appdb.users grouped by day.”, all secured with Microsoft Entra authentication for enterprise-grade security. This integration delivers a unified, secure interface for building intelligent, context-aware workflows across Azure services - accelerating insights and automation.

Learn more

Greater networking flexibility with Custom Port Support

Custom port support for Azure Database for MySQL is now generally available, giving organizations the flexibility to configure a custom port (between 25001 and 26000) during new server creation. This enhancement streamlines integration with legacy applications, supports strict network security policies, and helps avoid port conflicts in complex environments.

Supported across all network configurations - including public access, private access, and Private Link - custom port provisioning ensures every new MySQL server can be tailored to your needs. The managed experience remains seamless, with all administrative capabilities and integrations working as before.

Learn more

Streamline migrations and compatibility with Lower Case Table Names support

Azure Database for MySQL now supports configuring lower_case_table_names server parameter during initial server creation for MySQL 8.0 and above, ensuring seamless alignment with your organization’s naming conventions. This setting is automatically inherited for restores and replicas, and cannot be modified.

Key Benefits:

Simplifies migrations by aligning naming conventions and reducing complexity.

Enhances compatibility with legacy systems that depend on case-insensitive table names.

Minimizes support dependency, enabling faster and smoother onboarding.

Learn more

Unlock New Capabilities with Private Preview Features at Ignite 2025

We’re excited to announce that you can now explore two powerful capabilities in early access - Reader Endpoint for seamless read scaling and Server Rename for greater flexibility in server management.

Scale reads effortlessly with Reader Endpoint (Private Preview)

We’re excited to announce that the Reader Endpoint feature for Azure Database for MySQL is now ready for private preview.

Reader Endpoint provides a dedicated read-only endpoint for read replicas, enabling automatic connection-based load balancing of read-only traffic across multiple replicas. This simplifies application architecture by offering a single endpoint for read operations, improving scalability and fault tolerance. Azure Database for MySQL supports up to 10 read replicas per primary server. By routing read-only traffic through the reader endpoint, application teams can efficiently manage connections and optimize performance without handling individual replica endpoints. Reader endpoints continuously monitor the health of replicas and automatically exclude any replica that exceeds the configured replication lag threshold or becomes unavailable.

To enroll in the preview, please submit your details using this form.

Limitations During Private Preview:

Only performance-based routing is supported in this preview.

Certain settings such as routing method and the option to attach new replicas to the reader endpoint can only be configured at creation time.

Only one reader endpoint can be created per replica group.

Including the primary server as a fallback for read traffic when no replicas are available is not supported in this preview.

Get flexibility in server management with Server Rename (Private Preview)

We’re excited to announce the Private Preview of Server Rename for Azure Database for MySQL. This feature lets you update the name of an existing MySQL server without recreating it, migrating data, or disrupting applications - making it easier to adopt clear, consistent naming. It provides a near zero-downtime path to a new hostname of the server.

To enroll in the preview, please submit your details using this form.

Limitations During Private Preview:

Primary server with read replicas: Renaming a primary server that has read replicas keeps replication healthy. However, the SHOW SLAVE STATUS output on the replicas will still display the old primary server's name. This is a display inconsistency only and does not affect replication.

Renaming is currently unsupported for servers using Customer Managed Key (CMK) encryption or Microsoft Entra Authentication (Entra Id).

Real-World Success: Azure Database for MySQL Powers Resilient Applications at Scale

Factorial

Factorial, a leading HR software provider, uses Azure Database for MySQL alongside Azure Kubernetes Service to deliver secure, scalable HR solutions for thousands of businesses worldwide. By leveraging Azure Database for MySQL’s reliability and seamless integration with cloud-native technologies, Factorial ensures high availability and rapid innovation for its customers. Learn more

YES (Youth Employment Service)

South Africa’s largest youth employment initiative, YES, operates at national scale by leveraging Azure Database for MySQL to deliver a resilient, centralized platform for real-time job matching, learning management, and career services - connecting thousands of young people and employers, and helping nearly 45 percent of participants secure permanent roles within six months. Learn more

Nasdaq

At Ignite 2025, Nasdaq will showcase how it uses Azure Database for MySQL - alongside Azure Database for PostgreSQL and other Azure products - to power a secure, resilient architecture that safeguards confidential data while unlocking new agentic AI capabilities. Learn more

These examples demonstrate that Azure Database for MySQL is trusted by industry leaders to build resilient, scalable applications - empowering organizations to innovate and grow with confidence.

We Value Your Feedback

Azure Database for MySQL is built for scale, resilience, and performance - ready to support your most demanding workloads. With every update, we’re focused on simplifying development, migration, and management so you can build with confidence. Explore the latest features and enhancements to see how Azure Database for MySQL meets your data needs today and in the future.

We welcome your feedback and invite you to share your experiences or suggestions at AskAzureDBforMySQL@service.microsoft.com

Stay up to date by visiting What's new in Azure Database for MySQL, and follow us on YouTube | LinkedIn | X for ongoing updates.

Thank you for choosing Azure Database for MySQL!

Building brighter futures: How YES tackles youth unemployment with Azure Database for MySQL

SaurabhKirtani — Thu, 13 Nov 2025 16:07:38 GMT

This article was co-authored by Malcolm MacDonald, CIO at YES, and Saurabh Kirtani, Senior Product Manager at Microsoft

Youth unemployment is one of South Africa’s most persistent challenges with more than half of young people struggling to secure their first job. At the same time, employers hesitate to hire people without experience, and youth cannot gain experience without employment. Solving this issue requires more than policy - it requires data systems that can match candidates to opportunities, track progress, and deliver pathways at scale.

YES, the Youth Employment Service, was created to change that equation. As South Africa’s largest youth employment initiative, YES connects young people with 12-month work placements, learning programs, and job-matching services. Every month, more than 40,000 youth and employer partners interact with the YES digital ecosystem. Built on Azure Database for MySQL, this ecosystem centralizes data, strengthens reliability, and adapts to the demands of a national program.

YES’s mission is to break the cycle of inexperience and unemployment and create pathways for youth into permanent work or entrepreneurship. The results are tangible: nearly 45 percent of participants find permanent jobs within six months of completing the program, and that percentage increases when entrepreneurs are included. By building a resilient data foundation, YES is positioned to expand these outcomes.

Turning database sprawl into one source of truth

Running a nationwide employment program is as much a technical challenge as it is a social one. YES serves two primary audiences through two portals: an employer portal where partners register programs and upload youth data, and a youth-facing portal with learning management systems (LMS) and rewards where participants complete training, track progress, and build CVs. At this scale, learning management, rewards, and career services demand live updates because thousands of app events - course completions, supervisor check-ins, CV edits - must sync across both portals instantly; otherwise rankings, rewards, and job-match alerts drift out of date.

Previously, each portal ran on its own database replica. Data diverged quickly, and a number of staff members spent their days reconciling records just to restore a single source of truth. Routine database work - patching windows, backups, and other maintenance - was also largely manual, compounding the operational drag.

Migrating to Azure Database for MySQL replaced that sprawl with a resilient core. Automated patching, half-hourly snapshots, and multi–availability zone setup for core database snapshots substituted manual interventions with built-in safeguards. With portals now calling into a centralized CRM via schema-aware APIs, the replicas - and the reconciliation loops they caused - are being retired. The unified dataset also feeds Power BI for program oversight without adding integration overhead.

YES now operates on a continuously updated foundation of learner and employer data - accurate in the moment and durable over time.

How a seamless CRM keeps YES in synch

YES’s portals, LMS, rewards program, and new career gateway, Skillquest, all connect to a central CRM that serves as the system of record for every participant and employer partner. Every interaction - whether a youth completes training, an employer uploads candidate data, or a CV is matched to a role - is logged instantly in the CRM and supported by Azure Database for MySQL.

By moving to an API-first architecture, these services now draw from the same underlying database instead of relying on redundant replicas. That shift not only simplified operations but also allowed YES to retire multiple databases entirely.

Rather than building individual portals, YES designed a configurable framework that adapts automatically as data models evolve. When a new field is added in the CRM, the system interprets and applies the change across connected portals instantly. With schema-aware APIs and a dynamic architecture, the IT team can roll out updates quickly and efficiently - without reengineering front-end systems.

Staying responsive under pressure

Supporting a national program means being ready for sudden surges in demand. When employer partners launch new initiatives, thousands of records may be registered at once. In the past, those spikes risked slowdowns that disrupted critical processes like sign-ups and data uploads.

On Azure Database for MySQL, elasticity is built in. During a slowdown on the sign-up portal, the team temporarily increased database capacity to stabilize performance. Once the issue was identified and corrected, resources were right-sized, restoring operation without disruption.

This ability to adjust database capacity in minutes is critical for YES. Elastic scaling not only prevents downtime during peak loads but also allows the IT team to diagnose and resolve issues without affecting the youth and employer partners who depend on its platforms. From learning modules to Skillquest’s career services, elasticity keeps every digital interaction reliable and responsive.

Nearing 100% uptime with reliability and security at scale

For a program that spans every province in South Africa, reliability is non-negotiable. Since migrating to Azure Database for MySQL, YES is nearing 100 percent database uptime during business hours, even as demand on its systems has grown.

Previously, backups and maintenance were handled manually - a time-consuming process that tied up staff resources. Today, half-hourly snapshots of the central database and nightly backups across other systems protect critical data. Multi–availability zone protection ensures that their core system stays resilient with the Host Support Partner performing annual disaster recovery tests to confirm the system can be restored in another region.

Security is built into the same foundation. Encryption at rest protects sensitive personal information, while Azure Advisor provides an evolving set of recommendations for configuration hardening. Each month, the YES team reviews Azure Advisor’s recommendations with their vendor, using them as a roadmap to guide implementation and future investments without requiring senior engineers on staff. YES also relies on Microsoft Defender extensively across its environment and is shifting VPN access into Microsoft Entra so remote staff can connect directly into Azure rather than routing through on-premises networks.

These practices translate directly into measurable efficiency. By automating resilience and compliance tasks that would otherwise require senior expertise, YES keeps its cost per job below 2,500 rand (about USD $140) per year - one of the lowest figures of its kind globally. Every rand saved in IT overhead expands the number of youths who can be supported through placements, training, and career pathways.

Expanding youth opportunities with AI and data

With a centralized, API-first foundation in place, YES is now building new services that extend beyond initial work placements. Skillquest, a career gateway for alumni not absorbed into permanent roles, allows youth to create CVs, showcase skills, and connect directly with employer partners searching for talent.

At the core of Skillquest is a vector-based AI matching system where youth CVs are vectorized and compared against job specifications, surfacing the best-fit opportunities and automatically alerting candidates to apply. The system also incorporates results from cognitive skill assessments - World Bank–designed games that measure reasoning, speed, and problem-solving ability. By combining vectorized CV data with cognitive assessments, Skillquest builds multidimensional profiles that employers can query with precision.

YES has also introduced a ranking system to highlight top-performing youth. Running on the same MySQL foundation as the LMS, it aggregates structured inputs - SCORM course completions, reward triggers, supervisor feedback, and SkillQuest cognitive assessments - and applies weighting rules to produce a composite score. With rankings recalculated in real time through the CRM and APIs, employers gain a deeper, data-driven picture of candidates while YES maintains an always-current record of every journey.

This architecture positions YES to scale its impact further, supporting internship and training programs not only in South Africa but potentially worldwide. By making systems more dynamic and adaptable, YES can evolve its services without re-architecting its infrastructure, ensuring that data continues to drive opportunity.

Building systems that build futures

YES demonstrates that solving youth unemployment requires more than vision - it requires resilient systems that can deliver opportunity at scale. By migrating to Azure Database for MySQL, YES replaced reconciliation bottlenecks with continuous clarity, added elasticity to meet demand, and achieved the resiliency and uptime needed to support a nationwide program.

For the IT team, tools like GitHub Copilot have been just as transformative. Most of the staff at YES are in their first jobs. Copilot gives them a way to learn quickly and take on projects that would normally require senior expertise. By extending Copilot to the people running the systems, YES can keep innovating with confidence.

And the impact extends beyond infrastructure. With emerging services like Skillquest and AI-powered job matching, the organization is expanding its reach and deepening its impact.

Join the conversation

Hear more from Malcolm MacDonald, CIO at YES, in an upcoming session of the Monthly Azure Database for MySQL webinar series. In the meantime, read more about YES in Microsoft's featured customer story and inspiring video to see how technology is driving real impact.

Custom Port Support in Azure Database for MySQL – Flexible Server is Now Generally Available

Elendil — Wed, 15 Oct 2025 13:00:00 GMT

We are excited to announce that custom port support for Azure Database for MySQL – Flexible Server is now generally available (GA). This long-requested feature gives you greater flexibility to align MySQL server deployments with your network and security requirements. By default, MySQL uses TCP port 3306; with this GA release, you can configure a custom port (between 25001 and 26000) when creating a new Azure Database for MySQL flexible server. This enables easier integration with legacy applications, helps comply with strict network security policies, and avoids port conflicts in complex environments.

What’s new in GA (vs. Public Preview): In the Public Preview (July 2025), custom ports were only supported for VNet-injected (private access) servers, with no support for public access or Private Link connectivity. Now, with GA, you can create custom-port servers in any network configuration – including both publicly accessible servers and those using Private Link (private endpoint) connectivity. In short, all new MySQL flexible servers can be created with a custom port, whether they are configured for public network access or deployed into a private virtual network.

Feature Highlights

Custom Port Range: Choose a port between 25001 and 26000 during server provisioning. (Only one custom port is supported per server.) This is in addition to the default MySQL port 3306, which remains available for use if needed.
Supported Scenarios: Custom ports are fully supported for new server creation, point-in-time restore (including cross-port restores), read replica setup, and High Availability (HA) deployments. You can perform a restore or set up a replica even if the source and target servers use different ports, and you can enable HA on a server configured with a non-default port.
Networking Flexibility: Supported on both public access and private access configurations. You can create servers with a custom port in public access mode (accessible via the internet with firewall rules) or in private access mode (injected into a VNet). Azure Private Link is also supported – meaning you can connect via a private endpoint to a MySQL server running on a custom port. This enhancement broadens the feature’s applicability beyond the preview’s limited scope, allowing usage in all network scenarios.
Managed Experience: The custom port feature is built into the managed service experience. Aside from specifying a different port number for client connections, there is no change in how you manage or operate the MySQL flexible server – all administrative capabilities and integrations (backup, monitoring, etc.) work as they do with the default port.

Current Limitations

Be aware of a couple of limitations at GA:

Port Immutable After Creation: You cannot change the server’s port after the server is created. If you need to use a different port, you will have to create a new server with that port. As a workaround, you can use Point-in-Time Restore (PITR) to quickly clone your database into a new server with the desired port (since cross-port restores are supported), rather than performing a full manual migration.
Geo-Replication/Geo-Restore: Cross-region operations like geo-restore and geo-replication are not yet supported for servers using a custom port. In other words, you cannot perform a geo-restore of a backup from a custom-port server, and you cannot create cross-region read replicas on custom port servers at this time. These capabilities are on the roadmap but remain unsupported in the current release.

Why Custom Ports?

Many enterprise developers and DBAs have asked for custom port support to accommodate specialized network scenarios. For example, some organizations enforce strict firewall rules or use non-standard ports for databases to meet internal security compliance requirements. Others may have legacy applications or multi-database setups that require MySQL to run on a port other than 3306 to avoid conflicts. The custom port feature addresses these needs by allowing you to select a non-default port during server creation, while Azure continues to handle all the usual PaaS management tasks. In short, you get the flexibility of a custom network configuration without losing the benefits of a fully managed database service.

Getting Started

Using a custom port is straightforward. At GA, the Azure portal’s create experience is the way to set a custom port (support in CLI/PowerShell/ARM will come later). In the portal, when you create a new Azure Database for MySQL – Flexible Server, you’ll find an option to specify the “Database port.” Provide any value between 25001 and 26000 as the port number for your server. Once the server is deployed, client applications should connect using the <servername>.mysql.database.azure.com hostname and the port you chose, instead of the default 3306. All other connection settings (such as SSL enforcement and credentials) remain the same.

Make sure to configure network access rules to allow traffic on your chosen port. For public access servers, this means updating the firewall rules or network security groups to permit the custom port. For private access or Private Link setups, ensure that your networking (NSGs, on-premises firewall rules, etc.) permits traffic on the custom port to reach the database.

Learn More

Custom port support is now GA and ready for production use, so we encourage you to try it out if your environment can benefit from it. For more details on Azure Database for MySQL – Flexible Server connectivity and custom ports, refer to the official documentation: Networking Overview - Azure Database for MySQL | Microsoft Learn

We look forward to seeing how you use this new capability to tailor your MySQL deployments. With custom port support now generally available, Azure Database for MySQL – Flexible Server offers even more flexibility to meet your organizational policies and integration needs, all while delivering a fully managed experience. Happy deploying!

September 2025 Recap: Azure Database for MySQL

karlaescobar — Thu, 09 Oct 2025 13:55:16 GMT

Join us live on our YouTube channel on October 15, 2025 for an exclusive webinar where we’ll dive deeper into the latest Azure Database for MySQL updates and answer your questions! Watch it live here.

Support for In-Place Major Version Upgrade from 8.0 to 8.4

We previously announced that Azure Database for MySQL version 8.4 is now generally available. We’re now happy to share that in-place major version upgrade is supported for MySQL servers from 8.0 to 8.4. If you’re currently on MySQL 5.7, you’ll first need to perform an in-place upgrade from 5.7 to 8.0, and then upgrade from 8.0 to 8.4. Learn more.

Near-Zero-Downtime Maintenance - General Availability

You can now take advantage of near-zero-downtime maintenance for Azure Database for MySQL with high availability (HA) enabled. This capability is now generally available and is supported by our new HA architecture based on a dedicated Azure Standard Load Balancer design. Thanks to the dedicated Standard Load Balancer design, maintenance is now faster and no longer impacted by client-side DNS caching, which previously caused brief connection drops in some scenarios. This enhancement ensures that your mission-critical workloads remain continuously available, even during infrastructure updates, helping you meet strict uptime requirements and maintain operational continuity. Learn more.

We would love your feedback

We look forward to your feedback as you explore these enhancements and continue building with Azure Database for MySQL. If you have any suggestions or queries about our service, please let us know by emailing us at AskAzureDBforMySQL@service.microsoft.com.

To learn more about what's new with Flexible Server, see What's new in Azure Database for MySQL - Flexible Server.

Stay tuned for more updates and announcements by following us on social media: YouTube | LinkedIn | X.

Thanks for being part of our community!

August 2025 Recap: Azure Database for MySQL

Vandhana_Mehta — Thu, 04 Sep 2025 13:00:00 GMT

We're excited to share a summary of the Azure Database for MySQL updates for the month of August 2025.

Join us live on our YouTube channel on September 11, 2025 for an exclusive webinar where we’ll dive deeper into these updates and answer your questions! Watch it live here.

Azure Database for MySQL 8.4 - General Availability

We’re excited to announce that Azure Database for MySQL now supports MySQL 8.4 in General Availability (GA). This means you can create new MySQL 8.4 servers on Azure fully supported for production workloads. MySQL 8.4 is a long-term supported release from the MySQL community, bringing the latest features and improvements while emphasizing stability. With Azure’s managed service, you get these new capabilities backed by Azure’s enterprise-grade reliability and support. In short, MySQL 8.4 GA opens the door for you to upgrade your databases and future-proof your MySQL environment on Azure. Learn more.

Cross subscription and cross resource-group placement in restore/replica provisioning workflow

You can now restore a server or create a read replica in a different subscription and resource group in Azure Database for MySQL – Flexible Server. This enhancement offers greater flexibility for cross-environment restores, resource organization, and subscription-level separation, helping meet governance and operational requirements. Learn more.

Ability to delete on-demand backup

You can now delete on-demand backups in Azure Database for MySQL – Flexible Server, giving you greater control over backup management and storage costs. This feature allows you to remove on-demand backups that are no longer needed, helping maintain a cleaner backup inventory and optimize resource usage. Learn more.

Unlocking Regional Insights with the Location Based Capabilities REST API

Managing MySQL Flexible Server deployments across Azure regions often means choosing the right Azure region for your MySQL deployment is critical. The new Location-Based Capability Set – List API helps you:

Retrieve real-time, region-specific capabilities.

Compare SKUs, storage options, backup retention, and HA configurations.

Integrate insights into automation pipelines for smarter deployments.

This API empowers architects and developers to make informed decisions, reduce misconfigurations, and accelerate deployment cycles. Learn more.

Stay Connected

To learn more about what's new with Flexible Server, see What's new in Azure Database for MySQL - Flexible Server.

Stay tuned for more updates and announcements by following us on social media: YouTube | LinkedIn | X.

Take care, and thanks for being part of our community!

Azure Database for MySQL 8.4 Now Generally Available

Elendil — Tue, 27 Jan 2026 08:49:51 GMT

Note (January 2026): The Business-Critical service tier referenced in this blog has been rebranded to Memory Optimized. This change reflects updated naming only; the underlying performance characteristics and use cases described here continue to apply.

We’re excited to announce that Azure Database for MySQL – Flexible Server now supports MySQL 8.4 in General Availability (GA). This means you can create new MySQL 8.4 servers on Azure fully supported for production workloads. MySQL 8.4 is a long-term supported release from the MySQL community, bringing the latest features and improvements while emphasizing stability. With Azure’s managed service, you get these new capabilities backed by Azure’s enterprise-grade reliability and support. In short, MySQL 8.4 GA opens the door for you to upgrade your databases and future-proof your MySQL environment on Azure.

Why Upgrade to MySQL 8.4?

Avoid End-of-Support Deadlines: If you’re running MySQL 5.7 or 8.0 on Azure, planning an upgrade is crucial. MySQL 5.7’s community support ended on October 31, 2023, and MySQL 8.0’s end-of-life is April 30, 2026. Azure’s standard support for these versions extends slightly beyond those dates (until March 31, 2026 for 5.7, and May 31, 2026 for 8.0). After those points, servers on 5.7 or 8.0 enter Extended Support, a paid support phase that provides critical fixes for up to three years (through 2029). Running your database in Extended Support means additional costs. Upgrading to MySQL 8.4 now ensures your database stays within standard support for years to come, sparing you the hassle of last-minute upgrades or extended support fees.

Benefits of MySQL 8.4: MySQL 8.4 is essentially an evolution of 8.0, so it brings numerous performance enhancements, security patches, and new SQL features that have been introduced since 8.0. Because it’s an LTS release, MySQL 8.4 is designed for stability – making it an ideal target for enterprises. Most applications that work on MySQL 8.0 will be compatible with 8.4 with little to no changes, but with 8.4 you gain improvements in areas like replication, query optimization, and JSON handling (among others) that can boost your application’s efficiency. Moreover, by standardizing on 8.4, you align with the version that will receive updates well into the future. In summary, upgrading means better reliability, availability, and security now, and assured support longevity.

Upgrading from MySQL 8.0 (In-Place Upgrade)

For current Azure Database for MySQL 8.0 users, moving to 8.4 is straightforward, thanks to our in-place major version upgrade capability. You can upgrade your existing 8.0 server to 8.4 on the same server instance, without dumping and restoring data. Here’s how it works:

Upgrade Availability: If you create a new MySQL 8.0 server today (post-GA), the option to upgrade to 8.4 is available immediately in the Azure portal or CLI. For existing 8.0 servers (those created before this GA release), the upgrade capability will become available after your next scheduled maintenance window. The September 2025 platform update is enabling this feature across all regions. Note: Azure will not auto-upgrade your server during that maintenance; it only enables the new version as an option. You remain in control of when to perform the major version upgrade.
Performing the Upgrade: Once the feature is enabled for your server, you can initiate the upgrade via the Azure portal, Azure CLI, or PowerShell. The process involves a downtime (the server will be taken offline and restarted on MySQL 8.4), so plan to execute during a maintenance window or low-traffic period. We strongly recommend taking a backup or snapshot before upgrading, as a precaution. For a step-by-step guide and best practices (including how to minimize downtime by using read replicas for the upgrade), refer to the official Azure documentation on https://learn.microsoft.com/azure/mysql/flexible-server/how-to-upgrade. In most cases, upgrading from 8.0 to 8.4 is completed within several minutes. After upgrade, your server retains the same endpoints, configuration, and data – just running on the new MySQL 8.4 engine.

Upgrading from MySQL 5.7 (Two-Step Path)

Upgrading from MySQL 5.7 to 8.4 requires a two-step approach, since a direct jump is not supported:

First upgrade 5.7 to 8.0: Azure MySQL Flexible Server supports in-place major upgrade from 5.7 to 8.0. This moves your server to a supported major version and is a necessary intermediate step (you cannot skip major versions in one go). MySQL 8.0 introduced some changes from 5.7 (for example, stricter SQL modes and a new default authentication plugin), so after upgrading to 8.0, test your application and fix any compatibility issues. Azure’s standard support for 5.7 runs until March 31, 2026, so you should aim to complete this step before then.
Then upgrade 8.0 to 8.4: With your server now on 8.0, you can use the in-place upgrade to 8.4 as described above. All Azure 8.0 servers will have the 8.4 upgrade option by the end of the next maintenance cycle (after the feature rollout in September 2025). Plan to perform the 8.0 → 8.4 upgrade at a convenient time, ideally well before MySQL 8.0’s support winds down in 2026. This final step ensures you’re on the latest GA version and out of the legacy support cycle.

Some customers may choose to migrate 5.7 to 8.4 by creating a new 8.4 server and importing data (using dump and restore or Azure Database Migration Service). This approach can be useful if you want to reorganize your environment or test in parallel. However, it will likely involve more downtime than the sequential in-place upgrades. Evaluate which method fits your needs – either way, now is the time to start, given that free support for 5.7 ends in less than two years.

Support Timeline Summary and Next Steps

To recap the support timelines and why upgrading matters:

MySQL 5.7: Community EOL: Oct 31, 2023. Azure standard support until: March 31, 2026. After that, servers enter extended support (critical fixes only, with additional charges) until March 31, 2029. Action: Plan to upgrade off 5.7 before Q1 2026 to stay within standard support.
MySQL 8.0: Community EOL: Apr 30, 2026. Azure standard support until: May 31, 2026. Extended support then runs to May 31, 2029. Action: Begin upgrading 8.0 instances to 8.4 in the coming months, rather than waiting until the last moment. The upgrade feature is available now (or after one maintenance cycle for older servers).
MySQL 8.4: GA start: Sep 2025 (now). This is the recommended target for all MySQL deployments on Azure going forward. It will be fully supported on Azure well beyond 2026, receiving regular updates and improvements as part of the Azure service. Action: Deploy new databases on 8.4 and upgrade existing 5.7/8.0 databases to 8.4 when feasible, to benefit from the latest features and long-term support.

Next Steps: Getting started with MySQL 8.4 on Azure is easy. You can create a new Azure Database for MySQL 8.4 server from the Azure Portal or via CLI today. For existing servers, review the https://learn.microsoft.com/azure/mysql/flexible-server/how-to-upgrade to choose your upgrade method (in-place with some downtime vs. replica method for minimal downtime) and schedule a time for the upgrade.

By moving to Azure Database for MySQL 8.4, you’re investing in a more stable, performant, and future-proof foundation for your applications. We’re thrilled to see customers embrace MySQL 8.4, and we’re committed to making your upgrade process as smooth as possible. Upgrade with confidence, and leverage the power of MySQL 8.4 in Azure to drive your business forward!

For more information or to provide feedback, contact Ask Azure Database For MySQL.

Unlocking Regional Insights with the Location Based Capabilities REST API

ramkumarchan — Thu, 21 Aug 2025 05:45:03 GMT

Managing MySQL Flexible Server deployments across Azure regions often means navigating differences in available features, SKUs, storage options, backup retention periods, or high availability configurations. These variations can directly impact performance, cost, and resilience, making it critical to choose the right region for each workload. That’s where the Location-Based Capability Set – List API comes in, providing a programmatic way to retrieve up-to-date, region-specific capabilities. With this API, architects and developers can quickly compare offerings across multiple regions, understand which configurations are supported, and align deployment strategies with organizational needs. Instead of relying on static documentation, teams can integrate these insights into automation pipelines, ensuring deployments are optimized for the latest regional capabilities. This enables informed decision-making, reduces the risk of misconfiguration, and accelerates the design-to-deployment cycle for MySQL Flexible Server workloads in Azure.

What Is This API?

This endpoint allows you to query the capabilities available for Azure Database for MySQL in a specific subscription and location. It's accessed with:

GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.DBforMySQL/locations/{locationName}/capabilitySets?api-version=2023-12-30

You can find the subscription ID from Subscriptions

You can find the list of regions supported by Azure Database for MySQL Flexible Server from Azure regions

The API returns comprehensive details such as supported high-availability modes (e.g. zone redundancy), server editions (like Burstable), storage configurations, zone placement, and geo-backup support.

A typical response from this API includes:

value: An array of Capability objects for each region.
Inside each Capability:
- id, name, and type: Azure Resource Manager metadata identifiers.
- properties.supportedFlexibleServerEditions: Lists available editions with attributes:
  - name (e.g. “GeneralPurpose”), defaultSku, defaultStorageSize
  - supportedStorageEditions: Details like name, minStorageSize, maxStorageSize, minBackupRetentionDays, maxBackupRetentionDays, minBackupIntervalHours, maxBackupIntervalHours
  - supportedSkus: Details like vCores, supportedZones, supportedHAMode, etc.
- properties.supportedServerVersions: Array of supported MySQL server versions (name field only).
- properties.supportedGeoBackupRegions: Regions eligible for geo-backup.
- systemData: Metadata with creation and last-modified timestamps and user/identity info.
nextLink: For paging through multiple capability sets

Interpreting Empty or Missing Values

If fields like supportedServerVersions or supportedFlexibleServerEditions appear empty (such as empty arrays), it means your subscription currently lacks access to create servers with those configurations in the selected region. This limitation is not an error; it reflects access or availability restrictions.

Resolution: File a support request with Azure to enable access for your subscription in the chosen region.

Why This API Matters

Deployment Validation: Before creating a server, you can verify if your subscription supports specific configurations, such as editions, zones, or server versions in the chosen region to avoid deployment errors. For example, absence of SKUs in a region can result in failures like "No available SKUs in this location".
Automation & Infrastructure as Code: Embedding regional capability checks in automated deployment pipelines ensures that infrastructure templates only target supported configurations, making scripts resilient and reducing manual intervention.
Enhanced Resilience Planning: You can programmatically detect if your region supports features like zone-redundant high availability, enabling better design for fault-tolerance across availability zones.
Improved Developer Experience: Developers gain clarity on feature availability per region. Instead of guessing or trial and error, they can accurately query supported server versions or editions before launching servers.
Pre-Emptive Error Handling: Rather than encountering obscure deployment errors, teams can pre-check and interpret empty or unavailable values, knowing that empty lists mean a lack of access, and that a support request may be needed to enable provisioning in that region.

Scripts for pre-deployment validation

Using this API in deployment automation enables region-aware, resilient, and standards-compliant deployment. The following scripts (Bash and PowerShell) can be used to programmatically query a region’s Azure Database for MySQL capabilities, extract key configuration details such as supported server versions and high-availability modes, and alert when your subscription lacks access in that region (prompting a support request). These scripts enable easier integration into automated workflows or deployment pipelines.

Bash Script

GetLocationCapabilities.sh

#!/usr/bin/env bash set -euo pipefail # Usage message function usage() { echo "Usage: $0 --subscriptionId <subscriptionId> --location <location>" exit 1 } # Parse named parameters using GNU getopt ARGS=$(getopt -o '' --long subscriptionId:,location: -n "$0" -- "$@") || usage eval set -- "$ARGS" while true; do case "$1" in --subscriptionId) subscriptionId="$2" shift 2 ;; --location) location="$2" shift 2 ;; --) shift break ;; *) usage ;; esac done # Validate required arguments if [[ -z "${subscriptionId-}" || -z "${location-}" ]]; then echo "Error: Missing required parameters." usage fi apiVersion="2023-12-30" uri="/subscriptions/${subscriptionId}/providers/Microsoft.DBforMySQL/locations/${location}/capabilitySets?api-version=${apiVersion}" echo "INFO: Calling API - GET $uri" # Execute API call with logging if response=$(az rest --method GET --uri "$uri" --output json --only-show-errors); then echo "INFO: API call succeeded" else echo "ERROR: API call failed" exit 1 fi data=$(echo "$response" | jq .) # Check for 'value' array if [[ "$(echo "$data" | jq '.value | length')" -lt 1 ]]; then echo "WARN: No capabilitySets returned — your subscription may lack access in region '$location'. Consider filing a support request." exit 0 fi echo -e "\nSupported MySQL server versions in region '$location':" supported_versions=$(echo "$response" | jq -r '.value[0].properties.supportedServerVersions // [] | .[]? | .name // empty') if [[ -n "$supported_versions" ]]; then echo "$supported_versions" | sed 's/^/- /' else echo " [Warning] No supported server versions found; your subscription may lack access in this region. Consider filing a support request." fi echo -e "\nAvailable Flexible Server editions and HA modes:" editions=$(echo "$response" | jq -c '.value[0].properties.supportedFlexibleServerEditions // [] | .[]?') if [[ -n "$editions" ]]; then while IFS= read -r edition; do name=$(jq -r '.name' <<< "$edition") echo "Edition: $name" jq -c '.supportedSkus[]?' <<< "$edition" | while IFS= read -r sku; do sku_name=$(jq -r '.name' <<< "$sku" ) hamodes=$(jq -r '.supportedHAMode | join(", ")' <<< "$sku") echo " SKU Name: $sku_name; HA Modes: $hamodes" done done <<< "$editions" else echo " [Warning] No server editions found; your subscription may lack access in this region. Consider filing a support request." fi

Usage Example

./GetLocationCapabilities.sh --subscriptionId 01234567-89ab-cdef-0123-456789abcdef --location eastus

PowerShell Script

GetLocationCapabilities.ps1

param( [Parameter(Mandatory = $true)][string]$SubscriptionId, [Parameter(Mandatory = $true)][string]$Location ) Connect-AzAccount -Subscription $SubscriptionId | Out-Null $apiVersion = "2023-12-30" $uri = "/subscriptions/$SubscriptionId/providers/Microsoft.DBforMySQL/locations/$Location/capabilitySets?api-version=$apiVersion" # Log request details Write-Host "INFO: Calling API - GET $uri" -ForegroundColor Cyan try { $response = Invoke-AzRestMethod -Method GET -Path $uri -ErrorAction Stop Write-Host "INFO: API call succeeded" -ForegroundColor Green } catch { Write-Host " ** REST API call failed **" -ForegroundColor Red Write-Host "Error Message: $($_.Exception.Message)" if ($_.Exception.Response) { # Attempt to extract HTTP status if available $status = $_.Exception.Response.StatusCode.value__ 2>$null if ($status) { Write-Host "Status Code: $status" } } return } $data = $response.Content | ConvertFrom-Json # Check if 'value' exists and has at least one item if (-not $data.value -or $data.value.Count -eq 0) { Write-Warning "No capabilitySets returned in the response. You may not have access in region '$Location'. Consider filing a support request." return } $capability = $data.value[0] # Supported server versions $supportedVersions = $capability.properties.supportedServerVersions | Select-Object -ExpandProperty name Write-Host "`nSupported MySQL server versions in '$Location':" if ($supportedVersions) { $supportedVersions | ForEach-Object { Write-Host "- $_" } } else { Write-Warning "No supported server versions available; your subscription may lack access in this region. Consider filing a support request." } # Flexible Server editions & HA modes Write-Host "`nAvailable Flexible Server editions and HA modes:" $editions = $capability.properties.supportedFlexibleServerEditions if ($editions) { foreach ($edition in $editions) { Write-Host "`nEdition: $($edition.name)" foreach ($sku in $edition.supportedSkus) { $haModes = $sku.supportedHAMode -join ", " Write-Host " SKU Name: $($sku.name); HA Modes: $haModes" } } } else { Write-Warning "No server editions available; your subscription may lack access in this region. Consider filing a support request." }

Usage Example

.\GetLocationCapabilities.ps1 -SubscriptionId "01234567-89ab-cdef-0123-456789abcdef" -Location "eastus"

These PowerShell and Bash scripts help you quickly check Azure Database for MySQL capabilities in a region to prevent deployment issues and ensure reliable provisioning workflows. You can modify these scripts to extract the required information from the API response.

Feel free to comment below or write to us with your feedback and queries at AskAzureDBforMySQL@service.microsoft.com

Announcing Extended Support for Azure Database for MySQL

Elendil — Wed, 11 Mar 2026 10:16:43 GMT

ℹ️ Important Note (March 2026): Based on customer feedback requesting additional time to complete major version upgrades, we have extended the grace period before extended support billing begins for Azure Database for MySQL:

MySQL 5.7: Extended support billing start date moved from April 1, 2026 to August 1, 2026.

MySQL 8.0: Extended support billing start date moved from June 1, 2026 to January 1, 2027.

This update provides customers additional time to plan, validate, and complete upgrades while maintaining service continuity and security. We continue to recommend upgrading to a supported MySQL version as early as possible to avoid extended support charges and benefit from the latest improvements.

As part of our ongoing commitment to customer success and operational continuity, we are introducing Extended Support for Azure Database for MySQL as a paid offering designed to help customers continue running workloads on older MySQL versions with confidence, even after community support ends.

Why Extended Support?

We initially planned to retire support for MySQL 5.7 in Azure by September 2025, aligning with the community’s end-of-life (EOL) timeline. However, after engaging with many of our customers, we learned that a significant number of users prefer to remain on MySQL 5.7 due to application dependencies and stability considerations. At the same time, MySQL 8.0 is also approaching its community EOL in 2026.

To support customers through these transitions, we’re launching Extended Support as a paid feature to provide our customers with additional time and flexibility to plan and execute upgrades, without compromising on security, reliability, or support.

What’s Included in Extended Support?

With Extended Support, customers will continue to receive:

SLA-backed availability: Your MySQL servers remain covered by Azure’s enterprise-grade SLA.
Security updates: We will continue to deliver critical security patches to help protect your workloads.
Technical support: Azure support engineers will remain available to assist with troubleshooting and operational issues.

Seamless and Predictable Experience

Automatic enrollment: Once a MySQL version reaches community EOL, Azure-managed servers running that version will automatically enter Extended Support—no action is required from customers.
Grace period: Billing for Extended Support will begin one month after the community EOL date, giving customers time to plan.
Pay-as-you-go pricing: Extended Support will be billed per vCore per hour, with no upfront commitment.
Automatic exit: Once a server is upgraded to a supported community version, it will automatically exit Extended Support and billing will stop.

Pricing and Availability

The pricing for Extended Support will be announced by Q3 2025 and will be available via the Azure pricing calculator at that time.

Support Timeline for MySQL 5.7 and 8.0

ℹ️ Important note: Please refer to Version Support Policy | Microsoft Learn for latest extended support timeline.

Version	Azure Support Start Date	Community Retirement Date	Azure Standard Support End Date	Azure Extended Support Start Date	Azure Extended Support End Date
MySQL 5.7	March 20, 2018	October 31, 2023	~~March 31, 2026~~ July 31, 2026	~~April 1, 2026~~ August 1, 2026	March 31, 2029
MySQL 8.0	December 11, 2019	April 30, 2026	~~May 31, 2026~~ December 31, 2026	~~June 1, 2026~~ January 1, 2027	~~March 31, 2029~~ May 31, 2029

Version

Azure Support Start Date

Community Retirement Date

Azure Standard Support End Date

Azure Extended Support Start Date

Azure Extended Support End Date

MySQL 5.7

March 20, 2018

October 31, 2023

~~March 31, 2026~~

July 31, 2026

~~April 1, 2026~~
August 1, 2026

March 31, 2029

MySQL 8.0

December 11, 2019

April 30, 2026

~~May 31, 2026~~

December 31, 2026

~~June 1, 2026~~

January 1, 2027

~~March 31, 2029~~

May 31, 2029

Starting with MySQL 5.7, all future MySQL versions hosted on Azure will follow this Extended Support model after their respective community EOL dates.

How to Upgrade

If you prefer not to enroll in Extended Support, you can upgrade your Azure Database for MySQL server to a supported major version using one of the following in-place upgrade options:

In-Place upgrade on the same instance
Azure Database for MySQL – Flexible Server supports in-place major version upgrades. You can initiate the upgrade directly from the Azure portal, CLI, or ARM templates. This method preserves your server configuration, connection strings, and data, minimizing operational overhead.
Validate the upgrade before applying to production
To ensure a smooth upgrade experience, you can validate the upgrade using one of the following approaches:

- Replica-Based validation:
  Create a read replica of your production server, perform an in-place upgrade on the replica, and run validation tests. Once confirmed, you can either promote the replica or proceed with upgrading the primary server.
- PITR-Based validation:
  Use point-in-time restore (PITR) to create a new server from a recent backup of your production instance. Perform the upgrade on the restored server and validate your application behavior and performance before upgrading the production server.

Best Practices

- Always back up your data before initiating an upgrade.
- Review MySQL release notes for deprecated features and behavior changes.
- Monitor your application closely after the upgrade to ensure stability.

For detailed instructions, refer to Major Version Upgrade - Azure Database for MySQL | Microsoft Learn

July 2025 Recap: Azure Database for MySQL

SaurabhKirtani — Tue, 27 Jan 2026 09:18:32 GMT

We're excited to share a summary of the Azure Database for MySQL updates from the last couple of months.

Join us live on our YouTube channel on August 12, 2025, for an exclusive webinar where we’ll dive deeper into these updates and answer your questions. [Watch it live here.]

Highlights:

MCP Server for Azure Database for MySQL
One-click Self-Heal (Public Preview)
Extended Support for older MySQL versions
Accelerated logs in General Purpose service tier
Dedicated Azure Standard Load Balancer in Azure Database for MySQL (Public Preview)
Input and Output Bindings for Azure Functions (General Availability)
New Regions: Indonesia Central, Chile Central and Malaysia West
Custom Port Support (Public Preview)
Automate scheduling of on-demand backups
Configure backup interval for automated backups
Auto Initialization of Time Zones
Enable Auto-Scale of IOPS for Faster Restore and Replica Provisions
Key maintenance experience enhancements

MCP Server for Azure Database for MySQL

We are thrilled to introduce an MCP Server for integrating your AI models with data hosted in Azure Database for MySQL. By utilizing this server, you can effortlessly connect any AI application that supports MCP to your MySQL flexible server (using either MySQL password-based authentication or Microsoft Entra authentication methods), enabling you to provide your business data as meaningful context in a standardized and secure manner. Learn more.

One-click Self-Heal (Public Preview)

The Self-Heal feature in Azure Database for MySQL empowers customers to resolve common server issues independently, without needing to open a support case. It provides a one-click repair experience that helps restore service health quickly and safely. Learn more.

Extended Support for older MySQL versions

As part of our ongoing commitment to customer success and operational continuity, we are introducing Extended Support for Azure Database for MySQL as a paid offering designed to help customers continue running workloads on older MySQL versions with confidence, even after community support ends. Learn more.

Accelerated logs in General Purpose service tier

Accelerated logs are now supported in the General Purpose service tier of Azure Database for MySQL – Flexible Server. Previously available only in the Business Critical tier, this feature enhances performance and reduces transaction latency. Accelerated logs feature in General Purpose tier is available at an additional cost. Learn more.

Dedicated Azure Standard Load Balancer in Azure Database for MySQL (Public Preview)

Announcing the public preview of a dedicated Azure Standard Load Balancer in Azure Database for MySQL - Flexible Server for high availability-enabled servers. With this feature, a high availability configuration gets the benefit of a dedicated Standard Load Balancer, including low latency, high throughput network traffic distribution of front-end requests to backend servers. With Standard Load Balancer managing the MySQL data traffic path, you can enjoy a more optimized failover time for high availability servers. If you want to enable an SLB for your HA server, file a support ticket with Azure Support.

Input and Output Bindings for Azure Functions (General Availability)

Azure Database for MySQL Input and Output bindings for Azure Functions are now generally available, enabling seamless, declarative integration with MySQL databases. These bindings eliminate the need for manual connection or SQL logic, supporting both in-process and isolated worker models across C#, Python, Java, and JavaScript. Developers can now build event-driven, serverless apps that read, modify, and write MySQL data with minimal configuration and maximum flexibility. Learn more.

New Regions: Indonesia Central, Chile Central and Malaysia West

New regions rollout! Azure Database for MySQL flexible server is now available in Indonesia Central, Chile Central and Malaysia West, giving customers in and around these regions lower latency and data residency options. For the full list of supported regions, visit: Azure Regions

Custom Port Support (Public Preview)

Azure Database for MySQL (Flexible Server) now supports custom port selection (25001–26000) during server creation for VNet-injected servers. This enables better compliance with network security policies and integration with legacy systems, while supporting restore, HA, and read replicas. Learn more.

Automate scheduling of on-demand backups

Azure Database for MySQL now supports the ability to schedule on-demand backups using automation tasks. This feature gives you greater control and flexibility in managing on-demand backups for your Azure Database for MySQL Flexible Server instances. Learn more about how to schedule an automation task here.

Configure backup interval for automated backups

Azure Database for MySQL now supports the ability to configure backup interval for the automatic backups taken by the system to improve restore speed. This new feature optimizes the process by introducing more frequent snapshots, thereby reducing the number of binlogs that need to be replayed for point-in-time restore and minimizing overall restore time. Learn more about the feature here.

Auto Initialization of Time Zones

Time zones are automatically loaded during server creation, removing the need for customers to manually execute the mysql.az_load_timezone stored procedure afterwards to load the time zone. For more information, refer to the server parameter details for time_zone

Enable Auto-Scale of IOPS for Faster Restore and Replica Provisions

Azure Database for MySQL now supports the ability to enable autoscaling of IOPS for both the source and target servers during restore operations and replica provisioning workflows. This enhancement helps accelerate the restore and replica provisioning process by temporarily boosting IOPS to meet the performance demands of these operations. Once provisioning is complete, you can disable the autoscale IOPS setting. To learn more, visit Point-in-time restore.

Key maintenance experience enhancements

Virtual Canary: Virtual Canary is intended for non-production workloads that want to validate updates early. Servers under this policy receive updates ahead of general availability and do not follow the standard update cadence - there’s no guaranteed 30-day interval and no 7-day advance notice. Burstable SKU servers are enrolled in the Virtual Canary policy by default.

Maintenance Batches: Our custom maintenance feature has long been there and is one of the favorite features for our customers. Staged custom maintenance features provide custom advanced control, you can assign the server to a batch (Batch 1 or Batch 2) to help stagger maintenance across environments like TEST and PROD.

Maintenance Rollout Status Check (public preview): Each maintenance event includes a Tracking ID. Clicking this ID opens a detailed view of all servers in your subscription that are part of the same maintenance rollout. This gives you a consolidated overview across your fleet - no need to check each server individually or rely solely on email notifications.
Learn more.

Stay Connected

To learn more about what's new with Flexible Server, see What's new in Azure Database for MySQL - Flexible Server.

Stay tuned for more updates and announcements by following us on social media: YouTube | LinkedIn | X.

Take care, and thanks for being part of our community!

Now in Public Preview: Custom Port Support in Azure Database for MySQL – Flexible Server

Aditi_Gupta — Thu, 10 Jul 2025 22:16:02 GMT

Why Custom Ports?

By default, MySQL servers listen on port 3306. While this works well for most setups, some organizations need custom port configurations—for example, to comply with network security policies, reduce port conflicts, or streamline integration with legacy systems.

With this update, you can now choose a custom port number when creating your VNet-injected MySQL Flexible Server—giving you flexibility without compromising on the fully managed experience Azure offers.

Key Capabilities

Flexible Port Selection: Choose any port between 25001 and 26000 during server creation.
Seamless Restore and HA: Use custom ports with supported operations such as restore, read replica creation, and high availability.
One Port per Server: Each server supports a single custom port configuration.

What’s Supported (and What’s Not)

Supported in Public Preview:

VNet-injected servers
New server creation with a custom port
Restores across different ports
Read replica creation
High Availability (HA) on custom ports

Current Limitations:

Updating the port after server creation
Geo-restore and geo-replication
Public access and Private Link (coming soon)

Designed for Secure, Custom Deployments

This feature is ideal for customers operating in tightly controlled network environments or managing complex workloads that demand specific port configurations. During the preview, custom port support is available for VNet-injected servers only—offering an added layer of network isolation and security.

For more details, visit the Azure Database for MySQL documentation - Networking Overview - Azure Database for MySQL - Flexible Server | Microsoft Learn and Manage Virtual Networks - Azure Portal - Azure Database for MySQL - Flexible Server | Microsoft Learn.

We can’t wait to hear how you use this new capability to streamline your MySQL deployments! If you have any feedback or questions about the information provided above, please leave a comment below or email us at AskAzureDBforMySQL@service.microsoft.com. Thank you!

Boost your MySQL apps: why enterprises are migrating MySQL databases to Azure

TeneilLawrence — Wed, 02 Jul 2025 15:00:00 GMT

MySQL is one of the world’s most popular open-source databases, and for good reason. It’s cost-effective, scalable, and familiar to millions of developers. But if your enterprise is running MySQL on-premises, you might be missing out on huge benefits in cost savings, performance, and agility. Recent findings from an ESG Economic Validation report, commissioned by Microsoft, reveal just how advantageous it is to migrate on-premises MySQL databases to Azure’s fully managed database- as -a -service platform.

Read the full MySQL report

TL;DR – benefits of migrating to Azure Database for MySQL

Managing data security, quality and privacy as well as general database management are among the most significant challenges facing developer teams. Some even report that database technology is evolving faster than they’re able to keep up with. Migrating to Azure’s fully managed service offloads these responsibilities so teams can focus fully on projects that move their business forward. Some benefits of moving from on premises to Azure Database for MySQL highlighted in the report include:

54% lower total cost of ownership

86% lower MySQL admin costs

25% increase in development velocity

“Our developers can now focus on their core job: creating code. We now put out 8 releases per year compared to 2 when we were on premises. This gets features and fixes in the hands of our customers sooner.”

Review the Azure Database for MySQL Economic Validation Infographic

Zooming in – how fully managed open-source databases on Azure deliver economic wins for the enterprise

More than 50% lower costs and total cost of ownership

Azure’s fully managed MySQL service delivers the same (or better) database capabilities for almost half the cost. By one estimate, a company could save millions over a few years and even see an ROI above 90% from the migration when factoring in both cost savings and new revenue opportunities. These savings come from a few key areas:

No more hardware and maintenance expenses: On-premises MySQL deployments require investing in servers, storage, networking gear – plus ongoing power, cooling, and data center space. Azure Database for MySQL eliminates those needs entirely. You don’t buy or maintain hardware; Microsoft handles the infrastructure.

Drastically reduced admin overhead: Companies in the study reported an 86% reduction in the cost of MySQL administration after migrating to Azure. All the routine tasks—installing updates, patching OS and MySQL versions, tuning performance, taking backups, managing high availability—are handled by Azure as part of the service.

Pay-as-you-go efficiency: On-premises setups often over-provision resources to handle peak loads, which wastes money during lulls. Azure can scale resources on-demand, so you’re never stuck paying for idle capacity. You can also use cost controls like burstable instances for dev/test, stop/start to pause servers, and reserved instances for discounts.

Included extras: Many capabilities that would incur extra cost on-premises (or require separate licenses) are bundled into Azure Database for MySQL. For example, security features, monitoring and performance tuning tools, backup storage, and high availability options come built-in at no extra charge in Azure’s service tiers.

Improved performance and scalability

Beyond cost, Azure Database for MySQL helps your applications run faster and scale seamlessly to meet demand. In on-premises environments, you might need to tune configs, add hardware, or handle sharding as usage grows. Azure takes a lot of that burden away and offers cloud-scale performance out of the box:

Better throughput: Azure’s managed MySQL runs on high-performance cloud infrastructure (with fast SSD storage, plenty of memory, and low-latency networking). Microsoft has also added capabilities like accelerated I/O logs and intelligent caching that improve MySQL’s throughput and response times compared to typical on-premises setups.

Elastic scaling on demand: With Azure, scaling up a MySQL server is as simple as a configuration change. No new hardware is required. You can scale vertically (bigger machine) or horizontally (add read replicas) in minutes. Azure even supports autoscaling of IOPS and storage based on set thresholds. This flexibility means your database can handle traffic spikes or growth without manual intervention.

No wasted capacity: On-premises, you often must deploy extra servers “just in case” future demand increases, and that hardware sits underutilized most of the time. Azure’s model avoids this waste. Enterprises reported that Azure’s ability to fine-tune resources helped them avoid overprovisioning and maintain a better price/performance mix.

Reliable high performance at scale: Whether you have 10 users or 10 million, Azure’s global infrastructure can scale to meet your needs. One customer in the study found that after migrating, they could provide MySQL services 5× faster than when they were on-premises.

Faster development cycles and greater developer productivity

For developers, one of the biggest wins of moving MySQL to Azure is time back to innovate. When you no longer have to babysit your database infrastructure, you can focus on building features and improving your applications. The ESG report highlighted that companies saw significantly improved developer productivity and agility after migrating.

Faster development: Organizations reported that their development cycles became 25% faster on average once on Azure. One customer shared that “our developers can now focus on their core job: creating code.” The customer went from shipping two software releases per year to eight releases per year after migrating to Azure.

Elimination of toil: Azure’s fully managed platform lifts the burden of routine DB administration from your team. No more worrying about backups, failover, or OS patches. The service continuously applies best practices and optimizations automatically, so your team doesn’t have to. Teams can be more agile because they’re not bogged down by lengthy processes or constant maintenance.

Faster time-to-market: ESG modeled that by releasing features earlier and more often, thanks to Azure MySQL, a mid-sized software company could realize an additional $15 million in revenue over three years by being first-to-market with new capabilities can capture customers and market share.

Stronger security and high availability

Running MySQL in Azure doesn’t just make life easier and cheaper. It also makes your databases more secure and resilient. Enterprises often struggle to keep up with patches, security threats, and high availability when managing databases on-premises. Azure Database for MySQL is hardened with enterprise-grade security and reliability features that can significantly reduce your risk.

Fully managed security updates: In the ESG survey, nearly half of organizations (46%) said they needed outside expertise to help manage database platforms on-premises often because of the complexity of securing and tuning them. Azure takes care of patching the MySQL engine and underlying OS for you, ensuring you’re always on a supported, secure version.

Enhanced data protection: By default, Azure Database for MySQL encrypts data at rest and in transit. It also offers network isolation options to lock down access to your database. Many customers found that after migrating, their security posture was stronger than before. They could easily implement role-based access control via Azure AD, set up threat detection alerts, and use Azure’s monitoring to audit activity with just a few clicks.

High availability and disaster recovery built In: Azure Database for MySQL can be deployed with high availability configurations across availability zones. In case of an outage, it can switch to a standby replica usually in under 60 seconds, dramatically reducing downtime for your apps. Companies in the study experienced 70% less downtime incidents after moving to Azure.

Compliance and governance: Azure Database for MySQL is compliant with a broad set of industry standards and certifications, easing the audit burden. Many organizations found that moving to Azure made it simpler to adhere to internal security policies and compliance standards because so many controls are built into the platform.

Enterprise-ready MySQL is just a few clicks away

Azure provides a hardened, enterprise-ready environment for MySQL that most companies would be hard-pressed to build on their own. By entrusting MySQL to Azure’s managed service, you benefit from Microsoft’s investments in security and infrastructure resiliency. The result is peace of mind: your data is safer, your databases are more stable, and your team has far fewer 3 AM incidents to deal with.

Read the full report for more details about the quantified benefits and customer testimonials. If you’re ready to start your journey, check out our migration guides. With Azure’s fully managed open-source databases, you can supercharge your data strategy, empower your developers, and ultimately accelerate your path to an AI-driven future.

Model Context Protocol (MCP) Server for Azure Database for MySQL

ramkumarchan — Mon, 02 Jun 2025 16:00:00 GMT

The Model Context Protocol (MCP) is an open standard designed to facilitate seamless integration between AI applications and various external systems, including tools, data sources, and resources. MCP aims to standardize how AI models, such as large language models (LLMs), interact with external tools and data sources. MCP enables developers to build AI applications that can easily connect to MCP servers, which expose specific capabilities through the standardized protocol. This protocol helps reduce development effort by allowing a “write once, work everywhere” approach, ensuring that any AI application can utilize MCP servers without additional work.

The Model Context Protocol (MCP) offers several key benefits that make it a compelling choice for integrating AI applications with external systems:

Simplified integration: MCP provides a standardized way for AI models to interact with external tools and data sources, reducing the need for custom integration code for each service.
Tool discovery and self-description: MCP servers can expose specific capabilities through the protocol, allowing AI models to discover and utilize these tools without additional configuration.
Consistent security model: MCP ensures a consistent security framework for interactions between AI models and external systems, enhancing the overall security of the integration.
Built for local and cloud Resources: MCP supports both local and cloud-based resources, making it versatile for various deployment scenarios.
Enhanced developer experience: MCP's standardized approach reduces development effort by allowing a “write once, work everywhere” methodology, ensuring that any AI application can utilize MCP servers without additional work.
Future-proofing your AI stack: MCP is designed to be adaptable to future advancements in AI technology, ensuring that your AI applications remain compatible with new tools and data sources.

These advantages make MCP a powerful protocol for developers looking to streamline their AI integration processes and enhance the capabilities of their AI applications.

Azure Database for MySQL MCP Server

We are thrilled to introduce an MCP Server for integrating your AI models with data hosted in Azure Database for MySQL. By utilizing this server, you can effortlessly connect any AI application that supports MCP to your MySQL flexible server (using either MySQL password-based authentication or Microsoft Entra authentication methods), enabling you to provide your business data as meaningful context in a standardized and secure manner.

This server exposes the following tools, which can be invoked by MCP Clients in your AI agents, AI applications or tools like Claude Desktop and Visual Studio Code:

List all databases in your Azure Database for MySQL flexible server instance.
List all tables in a database along with their schema information.
Execute read queries to retrieve data from your database.
Insert or update records in your database.
Create a new table or drop an existing table in your database.
List Azure Database for MySQL flexible server configuration, including its MySQL version, and compute and storage configurations. *
Retrieve specific server parameter values. *

*Available when using Microsoft Entra authentication method

Getting started

In this section, we’ll show you how to use the MCP server with Claude Desktop and Visual Studio Code to gain valuable insights and visualizations from your databases through natural language queries!

Before diving in, please refer to our GitHub repository: azure-mysql/azure-mysql-mcp to ensure all the prerequisites are in place. You'll also find detailed onboarding guidance and the MCP server code available there.

Install the Azure Database for MySQL MCP Server

1. Clone the azure-mysql repository:

git clone https://github.com/Azure/azure-mysql.git cd azure-mysql cd azure-mysql-mcp

2. Create a virtual environment:

python -m venv azure-mysql-mcp-venv .\azure-mysql-mcp-venv\Scripts\activate.bat

Note: The above commands are applicable to Windows OS. For users of other operating systems, please refer to the full guide in the GitHub repository.

3. Install the dependencies:

pip install mcp pip install mysql-connector-python pip install azure-mgmt-mysqlflexibleservers pip install azure-identity

Use the MCP Server with Claude Desktop

1. In the Claude Desktop app, navigate to the “Settings” pane, select the “Developer” tab and click on “Edit Config”.

2. Open the “claude_desktop_config.json” file and add the following configuration to the “mcpServers” section to configure the Azure Database for MySQL MCP server:

{ "mcpServers": { "azure-mysql-mcp": { "command": "<path to the virtual environment>\\azure-mysql-mcp-venv\\Scripts\\python", "args": [ "<path to azure_mysql_mcp.py file>\\azure_mysql_mcp.py" ], "env": { "MYSQLHOST": "<Fully qualified name of your Azure Database for MySQL instance>", "MYSQLUSER": "<Your Azure Database for MySQL username>", "MYSQLPASSWORD": "<Your Azure Database for MySQL password>" } } } }

Note: In this example, we use password-based authentication to connect the MCP Server to Azure Database for MySQL for testing purposes only. However, we recommend using Microsoft Entra authentication. Please refer to these instructions for guidance.

3. Restart the Claude Desktop app.

4. Upon restarting, Click on the “Search and tools” icon at the bottom of the input box. Selecting this icon will display the tools exposed by the MCP Server

You are now all set to start interacting with your data using natural language queries through Claude Desktop!

Here is an example of creating an interactive Histogram of the distribution of Petal Length in the iris dataset.

Here is an example of querying the server parameters:

Here is an example of querying the server properties:

Use the MCP Server with Visual Studio Code

1. In Visual Studio Code, navigate to “File”, select “Preferences” and then choose “Settings”.

2. Search for “MCP” and select “Edit in settings.json”.

3. Add the following configuration to the “mcp” section of the “settings.json” file:

{ "mcp": { "inputs": [], "servers": { "azure-mysql-mcp": { "command": "<path to the virtual environment>\\azure-mysql-mcp-venv\\Scripts\\python", "args": [ "<path to azure_mysql_mcp.py file>\\azure_mysql_mcp.py" ], "env": { "MYSQLHOST": "<Fully qualified name of your Azure Database for MySQL instance>", "MYSQLUSER": "<Your Azure Database for MySQL username>", "MYSQLPASSWORD": "<Your Azure Database for MySQL password>" } } } } }

4. Select the “Copilot” icon in the upper-right corner to open the GitHub Copilot Chat window.

5. Next, choose “Agent mode” from the dropdown at the bottom of the chat input box.

6. Click on “Select Tools” to view the Tools exposed by the MCP Server.

You are now all set to start interacting with your data using natural language queries through Visual Studio Code!

What’s next?

Start using Model Context Protocol (MCP) today, to integrate your AI apps and agents with your data sources and services. We hope that the new Azure Database for MySQL MCP Server eases your MCP integration journey and helps you unlock the full combined potential of AI and your data stored in Azure Database for MySQL.

Stay tuned for updates as we further enhance the capabilities of the MCP Server to introduce new ways for AI models to interact with your business data. Meanwhile we look forward to your feedback and learning more about how this functionality benefits you.

Feel free to comment below or write to us with your feedback and queries at AskAzureDBforMySQL@service.microsoft.com.

Azure Database for MySQL bindings for Azure Functions (General Availability)

Sai_Kondapalli — Wed, 21 May 2025 19:59:03 GMT

We’re thrilled to announce the general availability (GA) of Azure Database for MySQL Input and Output bindings for Azure Functions—a powerful way to build event-driven, serverless applications that seamlessly integrate with your MySQL databases.

Key Capabilities

With this GA release, your applications can use:

Input bindings that allow your function to retrieve data from a MySQL database without writing any connection or query logic.
Output bindings that allow your function to insert or update data in a MySQL table without writing explicit SQL commands.
In addition you can use both the input and output bindings in the same function to read-modify-write data patterns. For example, retrieve a record, update a field, and write it back—all without managing connections or writing SQL.

These bindings are fully supported for both in-process and isolated worker models, giving you flexibility in how you build and deploy your Azure Functions.

How It Works

Azure Functions bindings abstract away the boilerplate code required to connect to external services. With the MySQL Input and Output bindings, you can now declaratively connect your serverless functions to your Azure Database for MySQL database with minimal configuration.

You can configure these bindings using attributes in C#, decorators in Python, or annotations in JavaScript/Java. The bindings use the MySql.Data.MySqlClient library under the hood and support Azure Database for MySQL Flexible Server.

Getting Started

To use the bindings, install the appropriate NuGet or npm package:

# For isolated worker model (C#) dotnet add package Microsoft.Azure.Functions.Worker.Extensions.MySql # For in-process model (C#) dotnet add package Microsoft.Azure.WebJobs.Extensions.MySql

Then, configure your function with a connection string and binding metadata.

Full samples for all the supported programming frameworks are available in our github repository.

Here is a sample C# in-process function example where you want to retrieve a user by ID, increment their login count, and save the updated record back to the MySQL database for lightweight data transformations, modifying status fields or updating counters and timestamps.

public class User { public int Id { get; set; } public string Name { get; set; } public int LoginCount { get; set; } } public static class UpdateLoginCountFunction { [FunctionName("UpdateLoginCount")] public static async Task<IActionResult> Run( [HttpTrigger(AuthorizationLevel.Function, "post", Route = "user/{id}/login")] HttpRequest req, [MySql("SELECT * FROM users WHERE id = @id", CommandType = System.Data.CommandType.Text, Parameters = "@id={id}", ConnectionStringSetting = "MySqlConnectionString")] User user, [MySql("users", ConnectionStringSetting = "MySqlConnectionString")] IAsyncCollector<User> userCollector, ILogger log) { if (user == null) { return new NotFoundObjectResult("User not found."); } // Modify the user object user.LoginCount += 1; // Write the updated user back to the database await userCollector.AddAsync(user); return new OkObjectResult($"Login count updated to {user.LoginCount} for user {user. Name}."); } }

Learn More

Conclusion

With input and output bindings for Azure Database for MySQL now generally available, building serverless apps on Azure with MySQL has never been simpler or more efficient. By eliminating the need for manual connection management and boilerplate code, these bindings empower you to focus on what matters most: building scalable, event-driven applications with clean, maintainable code.

Whether you're building real-time dashboards, automating workflows, or syncing data across systems, these bindings unlock new levels of productivity and performance. We can’t wait to see what you’ll build with them.

If you have any feedback or questions about the information provided above, please leave a comment below or email us at AskAzureDBforMySQL@service.microsoft.com. Thank you!