Database Sharding Strategies and Trade-Offs

Database sharding divides a large dataset across multiple independent database nodes. Each shard owns only part of the data, allowing storage capacity, write throughput, and query processing to grow beyond the limits of one server.

Sharding is not simply a database configuration change. It introduces routing, data placement, rebalancing, cross-shard transactions, operational coordination, and failure recovery concerns that become part of the application architecture.

A successful sharding design starts with access patterns and ownership boundaries. A poor shard key can create hot nodes, expensive scatter-gather queries, and migrations that are harder than the original scaling problem.

Table of Contents

• Why Databases Need Sharding
• Sharding Strategies
  • Range-Based Sharding
  • Hash-Based Sharding
  • Directory-Based Sharding
  • Geographic and Tenant-Based Sharding
• Designing the Shard Key
  • Cardinality and Distribution
  • Query Locality
  • Hot Shards
  • Compound Shard Keys
• Routing and Rebalancing
  • Application-Level Routing
  • Routing Services and Proxies
  • Resharding Production Data
• Cross-Shard Consistency and Failures
  • Cross-Shard Queries
  • Cross-Shard Transactions
  • Failure Scenarios
• Production Design Example
  • Multi-Tenant Logistics Platform
  • Request and Data Flow
  • Monitoring and Capacity Planning
• Ready-to-Use Example
  • Shard Catalog Schema
  • Python Shard Router
  • Moving Tenants Between Shards
  • Monitoring Shard Distribution
• Common Mistakes
• Production Readiness and Conclusion
  • Production Checklist
  • Conclusion
  • More Articles to Read

Why Databases Need Sharding

Replication creates additional copies of the same dataset and is effective for read scaling and failover. It does not usually divide write ownership: every write still reaches the primary and must eventually be applied by every replica.

Sharding changes the ownership model. Different records belong to different database nodes, so independent shards can process writes concurrently.

Without sharding:

All customers
      |
      v
+-------------------+
| One primary       |
| All writes        |
| All indexes       |
| Entire dataset    |
+-------------------+

With sharding:

Customer A-F   -> Shard 1
Customer G-M   -> Shard 2
Customer N-Z   -> Shard 3

Sharding becomes relevant when one database can no longer meet production requirements even after query optimization, indexing, caching, archival, partitioning, and reasonable vertical scaling.

Typical pressure points include:

• Storage capacity: the active dataset no longer fits comfortably on one node.
• Write throughput: transaction-log generation, CPU, locks, or storage latency limit writes.
• Maintenance duration: backups, restores, migrations, and index builds take too long.
• Tenant isolation: large customers interfere with smaller customers.
• Regional requirements: data must remain near users or within legal jurisdictions.
• Failure radius: one database failure currently affects every customer.

Sharding should be treated as a later-stage scaling decision. It increases capacity but removes many conveniences of a single transactional database.

Sharding Strategies

A sharding strategy defines how records are assigned to shards. The choice determines query locality, distribution quality, rebalancing difficulty, and the probability that one shard becomes disproportionately busy.

Range-Based Sharding

Range sharding assigns continuous key ranges to specific shards.

customer_id 1       - 1,000,000 -> Shard A
customer_id 1,000,001 - 2,000,000 -> Shard B
customer_id 2,000,001 - 3,000,000 -> Shard C

The approach is easy to understand and supports efficient range queries when the range key matches the access pattern.

Advantages

• Simple routing: shard ownership can be represented as ordered boundaries.
• Efficient range scans: adjacent values are stored together.
• Predictable data movement: one range can be split and migrated.
• Natural time-based placement: historical and recent records can be separated.

Disadvantages

• Hot newest range: sequential IDs or timestamps direct new writes to one shard.
• Uneven growth: some ranges may contain much more data than others.
• Traffic does not necessarily follow row count: a small range can receive most requests.

When to Use / Real-World Use Cases

Range sharding works well for archived events, time-series data, ordered account ranges, and systems that frequently query adjacent values. It is a poor default for monotonically increasing IDs under sustained write load unless the ranges are further distributed.

Hash-Based Sharding

Hash sharding computes a deterministic hash of the shard key and maps it to a shard or virtual bucket.

import hashlib


def shard_number(tenant_id: str, shard_count: int) -> int:
    # A stable hash is required. Python's built-in hash() is intentionally
    # randomized between processes and must not be used for persistent routing.
    digest = hashlib.sha256(tenant_id.encode("utf-8")).digest()
    numeric_value = int.from_bytes(digest[:8], byteorder="big")
    return numeric_value % shard_count

Advantages

• Even distribution: suitable keys are spread across shards.
• Reduced sequential hot spots: adjacent IDs usually reach different nodes.
• Fast deterministic routing: no catalog lookup may be required.
• Good point-query performance: one key identifies one shard.

Disadvantages

• Poor range locality: adjacent records are distributed across nodes.
• Naive modulo routing is hard to resize: changing the shard count remaps most keys.
• Large tenants can still create hot shards: hashing balances keys, not workload size.

When to Use / Real-World Use Cases

Hash sharding is effective for user profiles, sessions, message ownership, account records, and other point-access workloads. Use virtual buckets or consistent hashing when shard membership is expected to change.

Directory-Based Sharding

Directory-based sharding stores an explicit mapping from a business key to its shard.

tenant_1001 -> shard_east_1
tenant_1002 -> shard_east_2
tenant_1003 -> shard_enterprise_1

Advantages

• Flexible placement: large tenants can receive dedicated shards.
• Controlled migrations: mappings can change without changing business IDs.
• Supports exceptions: geographic, regulatory, and capacity requirements can influence placement.
• Stable logical ownership: physical topology can evolve independently.

Disadvantages

• Routing dependency: catalog availability becomes critical.
• Cache invalidation: stale mappings can send traffic to the wrong shard.
• More operational state: migrations require careful catalog updates.
• Additional lookup latency: uncached requests may need a metadata query.

When to Use / Real-World Use Cases

Directory-based routing is useful for multi-tenant SaaS platforms, enterprise customers with dedicated capacity, regional placement, and systems that expect frequent rebalancing.

Geographic and Tenant-Based Sharding

Geographic sharding assigns data according to region. Tenant-based sharding keeps all data for one customer on one shard.

These approaches align infrastructure with business boundaries and often provide better query locality than arbitrary row-level distribution.

Designing the Shard Key

The shard key is the most important sharding decision because it determines where data is stored and which queries can remain local to one database.

Changing a shard key after the system reaches production usually requires a large data migration, dual routing, and temporary support for two ownership models.

Cardinality and Distribution

A useful shard key must have enough distinct values to distribute records across many shards. Low-cardinality keys such as status or subscription tier create only a few ownership groups.

-- Poor shard key candidate:
-- Only a few values exist, so traffic cannot be distributed widely.
SELECT status, count(*)
FROM orders
GROUP BY status;

-- Better candidate:
-- tenant_id has high cardinality and aligns with account ownership.
SELECT
    count(DISTINCT tenant_id) AS tenants,
    count(*) AS orders
FROM orders;

Distribution must be measured by more than row count. Request rate, write volume, storage size, and expensive queries can vary significantly between shard-key values.

Query Locality

The shard key should appear in the application’s most common queries. A query without the shard key may need to contact every shard.

-- Local query: tenant_id identifies one shard.
SELECT id, status, created_at
FROM shipments
WHERE tenant_id = :tenant_id
  AND id = :shipment_id;

-- Potential scatter-gather query:
-- email does not identify a shard unless a global directory exists.
SELECT id, tenant_id
FROM users
WHERE email = :email;

Global lookup requirements can be supported with a separate directory, search index, or globally replicated reference table, but every additional structure introduces synchronization concerns.

Hot Shards

A shard can become hot even when data is evenly distributed. One customer, product, region, or event can generate a disproportionate amount of traffic.

Common mitigations include:

• Dedicated placement: move large tenants to isolated shards.
• Virtual buckets: split logical ownership into smaller movable units.
• Write bucketing: add a controlled suffix to distribute extreme write volume.
• Caching: remove repetitive read traffic without changing ownership.
• Rate limiting: protect shared capacity from one tenant.

Compound Shard Keys

A compound key combines business locality with an additional distribution dimension.

(tenant_id, bucket)

tenant_42, bucket_0 -> Shard A
tenant_42, bucket_1 -> Shard B
tenant_42, bucket_2 -> Shard C

Compound keys help distribute large tenants but make tenant-wide queries more expensive. They should be introduced only when one tenant cannot fit or operate efficiently on one shard.

Routing and Rebalancing

Once data is distributed, every request needs a reliable method for finding the owning shard. Routing must remain correct during deployments, failovers, and migrations.

Application-Level Routing

Application routing keeps ownership decisions close to business context. Repository or data-access layers receive the shard key and select the appropriate connection pool.

This provides explicit control but requires consistent implementation across every service that accesses the database.

Routing Services and Proxies

A central routing service or database proxy can hide physical topology from applications.

API Service
    |
    | tenant_id
    v
Shard Router
    |
    +--> Shard Catalog
    |
    +--> Connection Pool: Shard A
    +--> Connection Pool: Shard B
    +--> Connection Pool: Shard C

Central routing simplifies clients but creates critical infrastructure. The routing layer must be highly available, horizontally scalable, and protected against stale shard mappings.

Resharding Production Data

Rebalancing moves ownership from one shard to another. It may be necessary when shards fill unevenly, tenants grow, regions change, or infrastructure is replaced.

A safe migration commonly follows these stages:

1. Create the destination shard and verify schema compatibility.
2. Copy an initial snapshot of the tenant or bucket.
3. Capture writes that occur during the copy.
4. Apply changes to the destination until replication lag is near zero.
5. Temporarily block or coordinate writes for the ownership cutover.
6. Update the routing catalog atomically.
7. Verify reads and writes on the destination.
8. Retain the source copy temporarily for rollback.
9. Remove old data only after the migration is confirmed.

Resharding should be designed before it is needed. A topology that cannot move individual tenants or buckets will eventually require a much larger migration.

Cross-Shard Consistency and Failures

Sharding reduces the scope of local transactions. Operations inside one shard can still use normal database transactions, constraints, and locks. Operations spanning shards require coordination outside a single database transaction.

Cross-Shard Queries

Scatter-gather queries send work to multiple shards and combine the results.

from __future__ import annotations

from concurrent.futures import ThreadPoolExecutor
from dataclasses import dataclass
from datetime import datetime
from typing import Protocol


@dataclass(frozen=True)
class ShipmentSummary:
    shipment_id: str
    tenant_id: str
    created_at: datetime


class ShipmentShard(Protocol):
    def load_recent_shipments(
        self,
        limit: int,
    ) -> list[ShipmentSummary]:
        ...


def load_global_recent_shipments(
    shards: list[ShipmentShard],
    limit: int,
) -> list[ShipmentSummary]:
    # Each shard returns its local top results. Querying in parallel reduces
    # latency, but the global request still depends on the slowest shard.
    with ThreadPoolExecutor(max_workers=len(shards)) as executor:
        result_sets = list(
            executor.map(
                lambda shard: shard.load_recent_shipments(limit),
                shards,
            )
        )

    combined = [
        shipment
        for result_set in result_sets
        for shipment in result_set
    ]

    return sorted(
        combined,
        key=lambda shipment: shipment.created_at,
        reverse=True,
    )[:limit]

Scatter-gather performance degrades as shard count grows. Global reporting should usually move to a data warehouse, analytics store, or asynchronously maintained read model.

Cross-Shard Transactions

A transaction that updates multiple shards may use distributed transactions, but the resulting coordination reduces availability and increases failure complexity.

Many systems instead use:

• Sagas: execute local transactions with compensating actions.
• Outbox events: commit state and an event atomically on the owning shard.
• Idempotent consumers: safely retry cross-shard updates.
• Reservation workflows: separate resource holds from final confirmation.
• Single-owner design: place data that changes together on the same shard.

Failure Scenarios

Sharded systems fail partially. One shard may be unavailable while the rest of the platform continues operating.

• One shard fails: only tenants assigned to that shard should be affected.
• Catalog fails: cached mappings may support existing traffic, but new or moved tenants may become unavailable.
• Stale router cache: requests may reach the previous owner after migration.
• Migration worker fails: copying must resume from a checkpoint without duplicating changes.
• Destination falls behind: cutover should be delayed until the change backlog is safe.
• Cross-shard workflow stops halfway: retries or compensating operations must complete the workflow.
• Shard storage fills: writes should be limited before the node reaches complete exhaustion.
• Deployment uses incompatible schemas: rolling deployments can fail against only some shards.

Health checks should expose shard-specific status. A global healthy response can hide an unavailable shard and produce misleading platform-level monitoring.

Production Design Example

Consider a logistics platform that stores shipments, carrier integrations, tracking events, invoices, and workflow state for thousands of freight-forwarding customers.

Multi-Tenant Logistics Platform

The platform uses tenant-based directory sharding. Every tenant receives a logical shard assignment stored in a central catalog.

                         +------------------+
Request with tenant_id --> API Gateway      |
                         +--------+---------+
                                  |
                                  v
                         +------------------+
                         | Application API  |
                         +--------+---------+
                                  |
                                  v
                         +------------------+
                         | Shard Router     |
                         +---+----------+---+
                             |          |
                    cached map          | catalog lookup
                             |          v
                             |   +--------------+
                             |   | Shard Catalog |
                             |   +--------------+
                             |
              +--------------+--------------+
              |                             |
              v                             v
       +-------------+               +-------------+
       | Shard A     |               | Shard B     |
       | Tenants 1-80|               | Tenants 81+ |
       +------+------+               +------+------+
              |                             |
              v                             v
       Read replicas                  Read replicas

Each shard publishes outbox events to a shared messaging platform.
Analytics consumes events into a separate warehouse.

Small tenants share general-purpose shards. Large tenants can be moved to dedicated shards without changing their tenant IDs or application URLs.

Request and Data Flow

Every API request is authenticated before database routing. The authenticated tenant ID becomes the routing key and is never accepted directly from untrusted request parameters.

Shipment creation follows this flow:

1. The authentication layer resolves the caller’s tenant.
2. The router loads the tenant’s shard assignment.
3. The API begins a local transaction on the owning shard.
4. The shipment and corresponding outbox event are inserted atomically.
5. The transaction commits.
6. An outbox worker publishes the event.
7. Tracking, notifications, and analytics consume the event asynchronously.

Operational queries remain tenant-local. Cross-tenant analytics never query application shards directly and instead use the warehouse populated by the event pipeline.

Monitoring and Capacity Planning

Capacity decisions are based on multiple dimensions:

• storage used by tenant and shard
• write transactions per second
• query latency by shard
• connection pool utilization
• transaction-log generation
• replication lag
• CPU and storage latency
• largest tenant as a percentage of shard capacity

Rebalancing begins before a shard reaches its hard limit. For example, migration may start when predicted 60-day storage reaches 70% or when sustained CPU exceeds the operational target.

Ready-to-Use Example

The following implementation uses a PostgreSQL shard catalog and a Python router. It demonstrates directory-based tenant placement, versioned mappings, bounded connection pools, and controlled tenant migration.

Shard Catalog Schema

CREATE TABLE database_shards (
    shard_id text PRIMARY KEY,
    writer_dsn_secret_name text NOT NULL,
    reader_dsn_secret_name text,
    region text NOT NULL,
    status text NOT NULL
        CHECK (status IN ('active', 'draining', 'offline')),
    capacity_weight integer NOT NULL DEFAULT 100
        CHECK (capacity_weight > 0),
    created_at timestamptz NOT NULL DEFAULT now(),
    updated_at timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE tenant_shard_assignments (
    tenant_id uuid PRIMARY KEY,
    shard_id text NOT NULL
        REFERENCES database_shards(shard_id),
    mapping_version bigint NOT NULL DEFAULT 1,
    migration_state text NOT NULL DEFAULT 'stable'
        CHECK (
            migration_state IN (
                'stable',
                'copying',
                'catching_up',
                'cutting_over',
                'verifying'
            )
        ),
    previous_shard_id text
        REFERENCES database_shards(shard_id),
    updated_at timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX tenant_shard_assignments_shard_idx
    ON tenant_shard_assignments (shard_id, tenant_id);

CREATE INDEX tenant_shard_assignments_migration_idx
    ON tenant_shard_assignments (migration_state)
    WHERE migration_state != 'stable';

-- Mapping versions allow routers to reject stale migration updates.
UPDATE tenant_shard_assignments
SET
    shard_id = :destination_shard_id,
    previous_shard_id = shard_id,
    mapping_version = mapping_version + 1,
    migration_state = 'verifying',
    updated_at = now()
WHERE tenant_id = :tenant_id
  AND mapping_version = :expected_mapping_version;

Python Shard Router

from __future__ import annotations

import time
from dataclasses import dataclass
from threading import Lock
from typing import Protocol
from uuid import UUID


@dataclass(frozen=True)
class ShardAssignment:
    tenant_id: UUID
    shard_id: str
    mapping_version: int
    migration_state: str


@dataclass
class CachedAssignment:
    assignment: ShardAssignment
    expires_at: float


class ShardCatalog(Protocol):
    def load_assignment(
        self,
        tenant_id: UUID,
    ) -> ShardAssignment:
        ...


class ConnectionRegistry(Protocol):
    def writer_for(self, shard_id: str) -> object:
        ...

    def reader_for(self, shard_id: str) -> object:
        ...


class ShardRouter:
    def __init__(
        self,
        catalog: ShardCatalog,
        connections: ConnectionRegistry,
        cache_ttl_seconds: float = 30.0,
    ):
        self._catalog = catalog
        self._connections = connections
        self._cache_ttl_seconds = cache_ttl_seconds
        self._cache: dict[UUID, CachedAssignment] = {}
        self._cache_lock = Lock()

    def assignment_for(
        self,
        tenant_id: UUID,
    ) -> ShardAssignment:
        now = time.monotonic()

        with self._cache_lock:
            cached = self._cache.get(tenant_id)

            if cached is not None and cached.expires_at > now:
                return cached.assignment

        assignment = self._catalog.load_assignment(tenant_id)

        with self._cache_lock:
            self._cache[tenant_id] = CachedAssignment(
                assignment=assignment,
                expires_at=now + self._cache_ttl_seconds,
            )

        return assignment

    def writer_for(self, tenant_id: UUID) -> object:
        assignment = self.assignment_for(tenant_id)

        # Writes during cutover require migration-specific coordination.
        # Ordinary requests should fail safely instead of writing to both
        # shards without a defined conflict-resolution protocol.
        if assignment.migration_state == "cutting_over":
            raise RuntimeError(
                "Tenant is temporarily unavailable during shard cutover"
            )

        return self._connections.writer_for(assignment.shard_id)

    def reader_for(self, tenant_id: UUID) -> object:
        assignment = self.assignment_for(tenant_id)
        return self._connections.reader_for(assignment.shard_id)

    def invalidate(
        self,
        tenant_id: UUID,
        minimum_mapping_version: int,
    ) -> None:
        with self._cache_lock:
            cached = self._cache.get(tenant_id)

            if cached is None:
                return

            if (
                cached.assignment.mapping_version
                < minimum_mapping_version
            ):
                self._cache.pop(tenant_id, None)

Production routers should refresh mappings through short-lived caching plus explicit invalidation events. Relying only on a long time-to-live creates an unsafe migration window.

Moving Tenants Between Shards

from __future__ import annotations

from dataclasses import dataclass
from enum import StrEnum
from typing import Protocol
from uuid import UUID


class MigrationStage(StrEnum):
    COPYING = "copying"
    CATCHING_UP = "catching_up"
    CUTTING_OVER = "cutting_over"
    VERIFYING = "verifying"
    COMPLETE = "complete"


@dataclass(frozen=True)
class MigrationCheckpoint:
    tenant_id: UUID
    source_shard_id: str
    destination_shard_id: str
    stage: MigrationStage
    last_copied_primary_key: str | None
    last_applied_change_position: str | None


class MigrationStore(Protocol):
    def load_checkpoint(
        self,
        tenant_id: UUID,
    ) -> MigrationCheckpoint:
        ...

    def save_checkpoint(
        self,
        checkpoint: MigrationCheckpoint,
    ) -> None:
        ...


class TenantMigrationService:
    def __init__(
        self,
        migration_store: MigrationStore,
        data_copier: object,
        change_replicator: object,
        catalog: object,
        verifier: object,
    ):
        self._migration_store = migration_store
        self._data_copier = data_copier
        self._change_replicator = change_replicator
        self._catalog = catalog
        self._verifier = verifier

    def run_next_step(self, tenant_id: UUID) -> None:
        checkpoint = self._migration_store.load_checkpoint(tenant_id)

        if checkpoint.stage == MigrationStage.COPYING:
            # Copy in bounded batches so one tenant migration does not create
            # long transactions or exhaust replication bandwidth.
            updated = self._data_copier.copy_next_batch(checkpoint)
            self._migration_store.save_checkpoint(updated)
            return

        if checkpoint.stage == MigrationStage.CATCHING_UP:
            updated = self._change_replicator.apply_next_batch(checkpoint)
            self._migration_store.save_checkpoint(updated)
            return

        if checkpoint.stage == MigrationStage.CUTTING_OVER:
            # Catalog cutover must compare the expected mapping version.
            # This prevents concurrent operators from moving the same tenant.
            self._catalog.cut_over_tenant(checkpoint)
            return

        if checkpoint.stage == MigrationStage.VERIFYING:
            self._verifier.verify_counts_and_checksums(checkpoint)
            return

Migration code must be restartable. Every batch should have a durable checkpoint so a worker crash does not restart a multi-terabyte copy from the beginning.

Monitoring Shard Distribution

-- Run on each shard and export the result to centralized monitoring.
SELECT
    current_database() AS database_name,
    count(DISTINCT tenant_id) AS tenant_count,
    count(*) AS shipment_count,
    pg_total_relation_size('shipments') AS shipment_bytes
FROM shipments;

-- Identify the largest tenants on a shard.
SELECT
    tenant_id,
    count(*) AS shipment_count,
    pg_size_pretty(
        sum(pg_column_size(shipments.*))
    ) AS estimated_row_size
FROM shipments
GROUP BY tenant_id
ORDER BY shipment_count DESC
LIMIT 20;

-- Detect long-running transactions that can interfere with migration,
-- maintenance, vacuum, and failover.
SELECT
    pid,
    usename,
    now() - xact_start AS transaction_age,
    state,
    wait_event_type,
    wait_event,
    query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY xact_start;

Database metrics should be joined with application telemetry. A technically healthy shard can still be overloaded by one tenant’s request pattern or an inefficient query introduced by a deployment.

Common Mistakes

Most sharding failures come from ownership and operational assumptions rather than the basic routing formula.

Production Readiness and Conclusion

A sharded database platform needs operating procedures for placement, routing, migrations, partial failures, backups, schema changes, and capacity management. These capabilities should exist before the first shard reaches its limit.

Production Checklist

• Confirm that one optimized database cannot meet projected requirements.
• Document the ownership boundary represented by the shard key.
• Measure key distribution by storage, writes, reads, and query cost.
• Keep records that change together on the same shard.
• Require the shard key in latency-sensitive APIs.
• Design a separate path for global lookups.
• Avoid naive modulo routing when shard count may change.
• Use virtual buckets or directory mappings for movable ownership.
• Version shard assignments.
• Use short-lived routing caches with explicit invalidation.
• Make the shard catalog highly available.
• Bound connection pools per application instance and shard.
• Monitor each shard independently.
• Alert on storage, CPU, latency, locks, and transaction-log growth.
• Track the largest tenants and fastest-growing buckets.
• Define capacity thresholds that trigger rebalancing.
• Make migrations incremental and restartable.
• Persist migration checkpoints.
• Verify copied data using counts and checksums.
• Define rollback behavior before every cutover.
• Prevent stale routers from writing to previous owners.
• Keep global analytics outside transactional shards.
• Use idempotency for retried cross-shard workflows.
• Prefer local transactions and asynchronous coordination.
• Test partial shard outages.
• Test catalog outages and stale-cache behavior.
• Back up and restore every shard independently.
• Track schema versions across all shards.
• Use backward-compatible database migrations.
• Practice tenant migration and shard evacuation before emergencies.

Conclusion

Database sharding increases storage and write capacity by dividing data ownership across independent database nodes. It is effective when workloads have clear ownership boundaries and most requests can be routed to one shard.

Range sharding preserves ordered locality but risks hot ranges. Hash sharding distributes keys well but makes range queries and resizing harder. Directory-based sharding adds routing infrastructure but provides the flexibility needed for tenant isolation, regional placement, and controlled migrations.

The most important design decision is not the number of shards. It is the shard key and the access patterns built around it. Systems that frequently require global queries or cross-shard transactions often move complexity from the database into application workflows, event pipelines, and operational tooling.

Key Takeaway: shard around stable business ownership, keep common transactions local, and design routing and rebalancing before production growth makes data movement urgent.

More Articles to Read

• Database Scaling Explained: Vertical vs Horizontal Scaling
• Replication and Read Replicas in Distributed Databases
• Designing High-Performance Database Schemas
• Partitioning Large Tables for Production Systems
• SQL vs NoSQL: Choosing the Right Database