Why should you care?

One box eventually hits limits; distribution needs intentional boundaries.

See it live — copy this example

Run in SQL Server Management Studio (SSMS) or Azure Data Studio.

-- Shard map sketch (metadata in a director DB)
USE DataVerse;
IF OBJECT_ID(N'dbo.ShardMap', N'U') IS NOT NULL DROP TABLE dbo.ShardMap;
CREATE TABLE dbo.ShardMap (
    TenantId INT NOT NULL PRIMARY KEY,
    ShardServer SYSNAME NOT NULL,
    ShardDatabase SYSNAME NOT NULL
);
INSERT INTO dbo.ShardMap (TenantId, ShardServer, ShardDatabase)
VALUES (1, N'sql-shard-01', N'DataVerse_T1'), (2, N'sql-shard-02', N'DataVerse_T2');
SELECT * FROM dbo.ShardMap WHERE TenantId = 1;

What happened?

• ShardMap tells the app which server/database holds a tenant.
• Each shard is a normal SQL database; the app routes connections.
• Cross-shard joins stay rare by design.

Practice next

1. Create ShardMap metadata.
2. Route a sample tenant to a shard name.
3. List operations that must stay single-shard.
4. Add Region column to ShardMap.
5. Write a pseudo connection-string builder using ShardServer/Database.

Remember

Distribute with a routing map. Keep most transactions single-shard. Operate backups/HA per node.

Tenant shards

Largest DataVerse tenants move to dedicated shards via ShardMap.

Outcome: Noisy neighbors stop hurting smaller tenants.