Scale pgvector in stages: optimize schema and queries, use appropriate indexes, increase memory/CPU/I/O, isolate background work, then add replicas for read capacity. Shard only when one primary or required isolation no longer fits. Distributed vector search must retrieve enough candidates per shard and merge globally while preserving tenant placement, authorization, freshness, and failure semantics.
Remove unnecessary data and indexes, fix plans, tune ANN from evidence, reduce dimensions/precision if quality allows, partition for pruning, batch ingestion, control connections, and move eligible reads to replicas. Vertical scaling often buys substantial simplicity.
They increase read capacity and isolate evaluation or analytics, but do not increase primary write capacity and introduce lag. Route read-after-write, deletion, and permission-sensitive requests according to visible-generation or lag policy. Replica promotion needs client and DNS/connection recovery.
Route by tenant when most queries stay inside a tenant. For global search, request more than k candidates from each relevant shard, merge by comparable distance in one model/metric, then rerank. Shard-local ANN approximation compounds global recall loss; evaluate end to end. Partial shard failure needs explicit behavior.
Extensions and services such as Citus or provider-specific distributed PostgreSQL may support pgvector with constraints that vary by version. Verify extension compatibility, operator pushdown, repartitioning, backups, upgrades, and global query behavior in primary documentation and a proof of concept.
Build a capacity curve for one node, then replay the same workload across replicas or shards. Measure primary write capacity, lag, global recall, fan-out, merge latency, hot tenants, resharding, node loss, backup/restore, and cost.
Given this pgvector capacity evidence and growth forecast [paste], create a staged scaling decision: optimize, vertical, isolate, replicas, partition, shard. For each, define trigger, benefit, consistency, recovery, quality impact, operational burden, experiment, and rollback.
Verification contract: No sharding recommendation is accepted without single-node saturation evidence and a global-recall plus failure test.