Weaviate can scale up (larger nodes) or scale out (more nodes). Scaling up can provision more resources per node, while scaling out adds nodes to the cluster to distribute data or enable high-availability (HA) setups with replicated data.

Some scaling decisions can be deferred until later, or changed. As best practice, estimate your future requirements, and set up development and staging deployments to mirror your planned or actual production setup.

Scaling decision matrix

If uptime is critical → Plan for high availability (HA)

• Requires multiple nodes with replication
• Consider the increased costs
• Example: Production applications that can't tolerate downtime

If you need high throughput or extreme scale → Scale out (more nodes)

• Better load distribution
• Allow cluster sizes exceeding single-machine capabilities
• Example: 100M+ objects or high-throughput consumer applications

If cost & convenience are priorities → Scale up (larger nodes)

• Single-node setups might be sufficient
• Example: Internal AI application with predictable load; some downtime tolerable

Critical planning consideration

Current limitation

You cannot re-shard existing collections, so plan ahead:

If you anticipate growth → Plan shard count upfront

• Rule: More shards than initial nodes enables future expansion
• Example: 8 shards across 2 nodes allows growth to 8 nodes

This means you should:

1. Estimate your maximum expected scale
2. Configure shard count accordingly from the start
3. Start with fewer nodes than shards to enable expansion

If you do not set a shard count, DEFAULT_SHARDING_COUNT (added in v1.37) decides it for you: it sets the desiredCount for new single-tenant collections, and its default of 0 means "use the cluster's node count". On a single-node cluster that gives you one shard, which is exactly the situation that blocks later expansion. Set the count explicitly rather than inheriting it. Multi-tenant collections are unaffected: there, each tenant is its own shard.

Planning Example

Current needs: 10M objects, single node
Future growth: Could reach 200M+ objects

Recommendation:
- Start: 4 shards on 1 node
- Scale to: 4 shards on 4 nodes as you grow
- This allows each shard to grow to 50M-100M objects before needing data migration

Moving shards after the fact

The shard count is fixed at creation, but shard placement is not. Replica movement (added in v1.32) lets you move or copy an individual shard replica from one node to another, which is how you rebalance after adding nodes, drain a node before decommissioning it, or raise the replication factor for one hot shard. It is off by default. Set REPLICA_MOVEMENT_ENABLED=true to use it.

Scaling up before scaling out

Sharding across nodes is often driven by the memory footprint of an HNSW index rather than by raw data volume. The disk-based HFresh index keeps only a compressed centroid index in memory and the rest on disk, so it can reduce the need to shard purely for memory reasons. Weigh that option before you add nodes just to fit vectors in RAM.

Learn more

• Concepts: Horizontal scaling | Concepts: Replication architecture

What's next?

With your database-level architecture decided, let's move to collection design - how you organize your data within Weaviate.