Skip to main content
Sharding partitions large collections into smaller segments (shards) based on field values. Instead of scanning an entire collection, queries target only the relevant shards — reducing read latency and improving throughput for high-volume datasets. For example, an orderbook collection with 50 markets and hourly snapshots can be sharded so that a query for market=SUI, hour=12 scans a single shard (~600KB) instead of the full dataset (~30GB).

Shard Key Types

OnDB supports three sharding strategies that can be combined in a hierarchy:

Setting Up Sharding

syncCollection creates or updates a collection’s indexes and sharding configuration in a single call. This is the recommended approach for new collections.
Method signature:
The result includes a sharding_configured field that confirms whether sharding was applied.

With setupSharding (Existing Collection)

Use setupSharding to add sharding to a collection that already exists and has data.
Method signature:

Shard Key Configuration

ShardingStrategy

ShardKey

Examples

Time-Series Data

Partition event logs by day for efficient date-range queries:

Multi-Tenant Data

Isolate tenant data into discrete shards:

High-Volume Writes

Distribute writes evenly across hash buckets to avoid hotspots:

Query Considerations

When enforce_in_queries is set to true, every query against the collection must include all shard key fields. This prevents full-collection scans and ensures queries hit only the relevant shards.
If you need to run occasional cross-shard queries (e.g., analytics), set enforce_in_queries: false. Be aware that queries without shard key filters will scan all shards.

Next Steps

Collections & Indexes

Schema design and index configuration

Query Builder

Fluent query API for filtering and sorting