Admin
Back to overviewSharding
Document chunks are natively hash-partitioned across 8 physical shards, keyed on organization — the same partitioning primitive a multi-node deployment would use to relocate shards onto separate database instances. This view is read-only: changing shard count is a schema migration, not exposed as a live control here.
Shard strategy
hash(org_id)
8 partitions
Your organization's shard
#3
Total chunks (platform)
14439
Total size (platform)
16.3 MB
| Shard | Partition | Chunks | Size | Distribution |
|---|---|---|---|---|
| #0 | document_chunks_p0 | 1840 | 2.1 MB | |
| #1 | document_chunks_p1 | 1712 | 1.9 MB | |
| #2 | document_chunks_p2 | 1995 | 2.3 MB | |
| #3your org | document_chunks_p3 | 1650 | 1.8 MB | |
| #4 | document_chunks_p4 | 1788 | 2.0 MB | |
| #5 | document_chunks_p5 | 1901 | 2.2 MB | |
| #6 | document_chunks_p6 | 1733 | 1.9 MB | |
| #7 | document_chunks_p7 | 1820 | 2.1 MB |
Ingestion queue
Jobs are claimed via SELECT ... FOR UPDATE SKIP LOCKED, so any number of worker invocations can drain this queue concurrently without ever double-processing a job — the primitive that lets ingestion throughput scale horizontally by adding more workers, with no separate lock manager.
Pending
1
Claimed
1
Done
7
Failed
1
Jobs completed — last 14 days
No data yet
Avg. processing latency
—
Time from claim to indexed, averaged across 0 completed jobs. Up to 5 jobs are drained per trigger call.
Manual trigger
Drains up to 5 pending jobs for your organization only. The same claim path also runs automatically after every upload, and is exposed platform-wide at POST /api/ingest/tick for external schedulers.