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

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

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.