Scaling & Limits

storh is file-first storage, not a relational query engine. The practical boundaries, with reference numbers from the benchmarks (50k records, Apple M1 Pro):

• Point access is effectively unbounded when the filesystem can handle the file count and the collection uses UUID-tail sharding. A point read is a few microseconds; a durable single-record write is fsync-bound at a few thousand per second.
• Segmented-log scans, cursor reads, and time-range reads are comfortable into roughly 1M records when segment sizes are configured for the workload. Bulk appends run at tens of thousands of records per second; torn-tail recovery replays hundreds of thousands of records per second on reopen.
• Queue operations append compact events to one durable log, so enqueue, claim, complete, requeue, and purge avoid one-file-per-job directory churn. Bulk claim and complete amortize locking and fsync across whole batches.
• Per-file field scans in DocStore degrade past roughly 10k records because every matching scan must walk individual files. Declare indexes for the fields you filter on; indexed equality queries answer in about a millisecond regardless of collection size.
• storh is not for ad-hoc relational queries, joins, secondary-index-heavy filtering, or analytical scans over many fields. Push collections into a SQL mirror when you need those read patterns; keep the system of record in a real database when you need multi-record transactions.

Use DocStore when point reads dominate, SegmentedLog when append and ordered reads dominate, and Queue for simple durable work dispatch. See Choosing an engine for a side-by-side comparison.