What Distributed SQL Means and What It Costs

A distributed SQL system presents SQL access while spreading important work or data across multiple components. The useful question is what becomes distributed, because different architectures move very different costs onto the network.

Separate the Different Architectures

Some systems partition data across nodes and execute queries near those partitions. Others separate compute from storage while retaining a primary write path. These designs can both use distributed components without offering identical write scaling.

Azure SQL Database Hyperscale separates compute, page servers, and a log service. That separation helps different components serve different roles. It does not mean that every compute replica independently accepts writes to the same database.

Other distributed databases combine partitioning, replication, and transaction coordination within their own engine. Read the product's actual architecture before translating a familiar term into a guarantee. A SQL endpoint does not make all storage designs equivalent.

Find Where the Data Lives

A partitioning key influences which node holds related data and which requests can stay local. A poor key can create a hot partition even when other nodes are quiet. More machines do not automatically spread a concentrated workload.

WITH Requests AS
(
    SELECT TenantId FROM (VALUES (1),(1),(1),(1),(2),(3)) AS v(TenantId)
)
SELECT TenantId, COUNT_BIG(*) AS request_count
FROM Requests
GROUP BY TenantId
ORDER BY request_count DESC;

This T-SQL example illustrates workload skew with invented input. It does not create a distributed database. Use your own request distribution to investigate whether the proposed placement key balances the work that matters.

Also ask whether large tenants can outgrow one partition. Splitting an already busy key can require a different model or operational process. Capacity planning needs the largest concentration, not only the average.

Follow a Write Through Its Required Acknowledgments

A durable write may require replication acknowledgments, transaction coordination, or remote log persistence. The exact path depends on the engine and chosen guarantees. Network distance becomes part of the operation's cost.

A transaction touching several partitions can require more coordination than one confined to a single partition. Replication consensus and multi-participant transaction commitment solve related but different problems. Do not reduce both to a vague claim that data is copied.

DECLARE @Lines table
(
    OrderId int, TenantId int, ProductId int, Quantity int
);
INSERT @Lines VALUES (1, 10, 100, 2), (1, 10, 101, 1);
SELECT OrderId, COUNT(DISTINCT TenantId) AS tenant_keys_touched
FROM @Lines
GROUP BY OrderId;

This query describes the logical keys touched by an example order. Whether that means one physical partition depends on the actual placement scheme. Map the business transaction onto the architecture rather than assuming locality from table names.

Check the Cost of Joins and Aggregates

A join can stay close to its data when related rows are colocated. Otherwise, the engine may move rows or intermediate results between nodes. A small final result can still require substantial distributed work.

WITH Sales AS
(
    SELECT * FROM (VALUES (1, N'East', 10), (2, N'West', 20))
         AS v(TenantId, Region, Amount)
)
SELECT Region, SUM(Amount) AS total_amount
FROM Sales
GROUP BY Region;

The SQL remains simple, but its physical execution can involve several partitions and a final aggregation stage. Inspect the distributed execution plan and network-related metrics provided by the product. Do not judge cost from statement length.

Separate throughput from individual-request latency when testing. A system may handle more concurrent work while one cross-region transaction takes longer. Both outcomes can be reasonable, depending on the requirement.

Include Failure and Operating Costs

Test what happens when a node or network link becomes unavailable. Ask which operations continue, which wait, and which return an uncertain outcome. The answer depends on quorum, placement, and consistency choices.

Include replica storage, network transfer, backup retention, observability, and operational staffing in the cost comparison. Managed services change who performs work, but they do not remove every cost. Data movement can become a material part of the bill.

Review driver behavior and retry requirements as carefully as SQL compatibility. An automatic retry must not repeat a business effect after an ambiguous commit. Use durable request identities where the application design requires them.

Choose Distribution for a Concrete Need

Start with a workload that needs the scale, availability, or geographic placement the design provides. Measure representative transactions from realistic client locations. Include skew, concurrent users, and failure recovery in the evaluation.

A single well-designed instance can be the simpler answer for some workloads. A distributed system can be the right answer for others. The decision should explain which limitation is being removed and which new costs are accepted.

Distributed SQL is not free scale, it is a different placement of work and guarantees.

This post was rewritten from scratch in September 2026. The original, published on 2012-08-01, was a short announcement about something that no longer exists. The address is the same, the subject is now something worth keeping.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.