Azure SQL Database Hyperscale now churns through transaction logs at up to 150 MiB per second, scales to 128 TB, and lets you spin up 30 named read replicas—capabilities that explode the old assumption that Hyperscale only makes sense for multi-terabyte databases. The same architecture also delivers serverless compute that scales up and down automatically, but as of mid-2026, one critical piece is still missing: it won’t pause itself when idle, a gap that can quietly run up your bill if you’re not paying attention.

What’s New in Azure SQL Hyperscale

Microsoft’s managed database platform has added several concrete improvements that redefine what Hyperscale can do for everyday workloads—not just the handful of applications that outgrow a 4 TB General Purpose limit.

Transaction log throughput now reaches 100 MiB per second on standard-series hardware and up to 150 MiB per second when you use premium-series or premium-series memory-optimised configurations. That’s per database, not per instance, so a single Hyperscale primary can ingest changes far faster than similarly priced General Purpose or even Business Critical tiers—without forcing you to buy extra cores just to satisfy the log-rate governor. Bulk imports, index rebuilds, heavy writes, and high-volume data churn all become less constrained by service-level limits.

Replica counts have expanded dramatically. You can attach up to four high-availability secondary replicas for failover and read-only workloads, and up to 30 named replicas per primary database. Named replicas get their own database name, compute size, and logical server within the same region, so you can hand a dedicated reporting endpoint to the data science team without giving them access to the transactional primary. Because replicas share the underlying distributed storage, provisioning one is closer to “near-instant” than to the hours a traditional full copy would take.

The 128 TB storage ceiling remains the headline number, but the more practical shift is how storage and compute now grow independently. You can add terabytes of historical data without touching the compute tier—and vice versa, scale up CPU for a seasonal crush without moving the database files. The decoupled architecture that made Hyperscale possible in the first place is finally reflected in a pricing model that charges compute and storage separately, after Microsoft dropped the SQL licence charge from new Hyperscale databases in December 2023.

Serverless compute landed more recently. It lets you define a vCore range—say, 0.5 to 8 vCores—and the service scales CPU up and down in near real time, billing per second for the exact vCore-seconds consumed. However, unlike the General Purpose serverless tier, Hyperscale serverless does not auto-pause. An idle Hyperscale database continues to consume at least the minimum vCore allocation, which means the compute meter never drops to zero even overnight or on weekends. Microsoft’s own documentation confirms that auto-pause and auto-resume are “currently only supported in the General Purpose service tier” as of July 2026.

What It Means for You

These architectural changes aren’t just academic—they directly affect how you design, operate, and pay for Azure SQL databases.

For Database Administrators

You’re getting tools that used to require elaborate workarounds. Need to separate reporting from transactional traffic? Point a named replica with its own connection string at the dashboarding tool, size it independently, and keep heavy aggregations off the primary. Recovery becomes faster too: point-in-time restores leverage storage snapshots, so Microsoft reports that most complete within 60 minutes regardless of database size—a world away from restore times that scale linearly with every terabyte.

But you’re also taking on new monitoring responsibilities. The local SSD cache (RBPEX) on a compute replica will serve hot pages at local speeds, but a broad, random-access working set can miss that cache and hit the remote page servers, adding latency. Replica lag is real: a read-only copy may trail the primary by seconds or more, so don’t assume immediate consistency. You’ll want to track cache hit ratios, replica lag, and log throughput throttling just as carefully as you once tracked disk queue depths.

For Developers and Architects

Hyperscale encourages cloud-native patterns: separate read and write paths, design for transient faults, and avoid cross-database dependencies. Named replicas are a gift for workload isolation, but they demand application awareness. If your code writes an order and then immediately reads it back from a replica, you may get stale data. Either route that read to the primary or build a consistency check into your logic.

Migration isn’t a simple backup-and-restore. Hyperscale still runs the Azure SQL Database engine, so anything that requires three-part names, SQL CLR, linked servers, or instance-level agents will block you. Microsoft’s assessment tools can flag these blockers, but a large, complex application may need significant refactoring even before you get to performance testing. Plan for a rehearsal migration with real data volumes and real concurrency.

For IT Decision-Makers and Cost Managers

The ability to scale storage and compute independently changes the procurement conversation. You no longer have to buy a massively over-provisioned instance just because the database might grow beyond 4 TB in two years. Addition of 30 named replicas, however, creates a new billing surface: every replica is a separate compute charge. Zone-redundant deployments multiply that further. The serverless tier’s inability to auto-pause means that for intermittent development, test, or disaster-recovery databases, General Purpose serverless can still be the cheaper choice—it really does shut down and stop billing when nobody is connected.

Existing Hyperscale databases that previously used the Azure Hybrid Benefit under the old licensing model should also be reviewed: Microsoft set a transition period that ends in December 2026, after which the newer simplified pricing rules will apply universally.

How We Got Here

Azure SQL Database Hyperscale entered public preview in 2018 and general availability in 2019 as an answer to the question, “What if my database needs to surpass 4 TB without sharding or re-architecting?” The early architecture separated compute from the log service and page servers, allowing storage to balloon almost independently of the database engine—but the marketing message was squarely aimed at massive, high-volume workloads. Initial pricing reinforced that perception, effectively charging a premium for the SQL Server licence on top of compute and storage.

Three shifts eroded that niche status. First, Microsoft expanded the feature set to include readable replicas, named replicas, and fast database copies based on storage snapshots. Second, in December 2023, the company removed the SQL software licence charge for new Hyperscale databases, cutting the cost delta with General Purpose enough that moderate databases could justify the tier’s architectural benefits. Third, serverless compute landed in preview and later GA, bringing the same per-second billing and autoscaling that General Purpose serverless enjoys—minus auto-pause.

The cycle of updates has been continuous: support for up to 192 vCores (still in preview for the largest sizes), zone-redundant availability, and incremental log-throughput bumps. The current capabilities, documented in a Redmond Magazine analysis published on July 22, 2026, reflect Microsoft’s ongoing effort to reposition Hyperscale as the default Azure SQL architecture rather than a specialist tool.

What to Do Now

Your next steps depend on where you are today.

  • If you’re building a new application, consider Hyperscale as the starting point—especially if you anticipate growth, need multiple read-only endpoints, or have write-heavy characteristics. Design for cloud-native patterns from day one: avoid instance-level dependencies, implement retry logic, and test read-after-write scenarios on replicas.
  • If you’re running a General Purpose database that is hitting log-rate limits, approaching 4 TB, or suffering from slow index maintenance, benchmark Hyperscale against a realistically sized test deployment. Use the same workload, measure both warm-cache and cold-cache performance, and compare total cost over a full business cycle.
  • If you rely on serverless auto-pause, stick with General Purpose serverless for intermittent databases; Hyperscale serverless will continue to incur minimum compute charges when idle. You can disable auto-scaling and go provisioned if you need the Hyperscale feature set but want a fixed bill.
  • If you already have a provisioned Hyperscale database, re-validate your licensing position before the December 2026 transition deadline. Also consider switching to serverless if your workload is bursty—just understand that the bill won’t drop to zero during quiet periods.
  • In all cases, put monitoring in place: watch log_IO_percent to see if you’re being throttled, track replica lag for any readable secondaries, and set cost alerts for each provisioned replica. A named replica left running at full compute for a development team that forgot about it can become an expensive oversight.

Outlook

Microsoft’s next logical move is to bring auto-pause to Hyperscale serverless. The technical hurdles are real—the distributed log service and page server architecture make pausing more complex than in General Purpose—but customer expectation is clear: “serverless” implies no compute cost when idle. If and when that arrives, Hyperscale will become even more compelling for development, staging, and DR environments.

Beyond auto-pause, watch for continued expansion of the compute ceiling (the 192-vCore tier), broader regional availability, and improvements to migration tooling that can handle the wave of SQL Server on-premises databases still waiting for a cloud home. As more everyday workloads adopt Hyperscale, best practices around replica routing, cache management, and cost governance will mature—turning what is still a power-user feature into the new normal.