Azure SQL Database

Azure SQL Database is Microsoft-managed SQL Server: the engine and its patches belong to Microsoft, you connect with a connection string, and you never manage a Windows instance, backup jobs or an availability group. It inherits the Azure compliance perimeter, with ISO 27001 and SOC audit scope and a BAA available for health data. For teams already on SQL Server, Azure Hybrid Benefit credits existing licences, which beats rewriting across clouds. Below: tiers, billing, region and provisioning.

Specs & pricing

The Azure SQL proposition: managed, compliant, identity-native

Three names get confused: Azure SQL Database (single database, PaaS), Azure SQL Managed Instance (whole-instance migration with SQL Server parity), and the older Azure SQL Data Warehouse family. Most new projects start with the single database. Against a SQL Server you run on a VM yourself, the differences come down to four things.

• Patching and availability belong to Microsoft — engine patches on a fixed cadence, zone redundancy needs no hand-built availability group
• Compliance evidence is ready — ISO/IEC 27001 and SOC reports feed straight into customer questionnaires, with a BAA for HIPAA scope
• Native Entra ID authentication — Entra ID users, groups and MFA connect directly, tracking enterprise expectations better than SQL logins
• A clear migration path — assess Hybrid Benefit, or move via Managed Instance at near one-for-one parity

Choosing a tier: General Purpose, Business Critical, Serverless, Hyperscale

How Azure SQL is billed: vCore, DTU, reservations and egress

• vCore model — compute and storage priced apart, so adding compute does not move data; new projects default here
• DTU model — the older bundled unit, still used in places; not directly comparable
• Reserved capacity — commit usage for a discount, Microsoft citing roughly 30–50% off
• Serverless auto-pause — pay only storage and the ability to resume, cited up to 90% saving
• Do not ignore egress — query results and cross-region access both bill, same-region generally does not

Region and availability zones: residency first, tier availability second

Deploying in Azure Hong Kong (East Asia) and Asia-Pacific latency

With the database in Hong Kong East Asia and app and users both in Asia-Pacific, interactive SQL round trips usually fall in the 20–40ms band, around 30–50ms to Singapore and 50–70ms to Tokyo and Seoul. Azure services in the same region use the internal network with no egress charge, which saves more than shaving latency does.

Azure SQL versus RDS for SQL Server, RDS MySQL and Cloud SQL

Opening an Azure SQL subscription and settling billing through us

1. Start with your load profile, concurrency and availability requirement, and we will recommend a tier
2. We handle the official Azure subscription registration, company entity and payment verification, and provision the account
3. You create the database in the portal. Get region and tier right at the start — tiers adjust later, a region change means a migration
4. Before launch, set max storage, alerts and a spend ceiling, and use slow query logs to find performance problems
5. Settle by USDT, other crypto or bank transfer, with no personal credit card and no personal identity documents

Five checks before the database goes live

• A region cannot change after creation — picking wrong means migrating, not editing a dropdown
• Auto-pause threshold too short — constant cold starts make responses slower
• No max storage — the database can grow automatically and so can the bill
• App and database in different regions — every query bills as egress
• Self-managed SQL logins instead of Entra ID — the hardest audit question