Single-Node → Multi-Node

Single-node capacity

A single Remem node (remem-server) handles, per the reference benchmark setup:

• Memories: Millions (bounded by RAM for the HNSW index — roughly 1GB per 500K memories at 384 dims)
• Vector search latency: ~4ms at 100K memories
• Write throughput: ~291 req/s (POST /memories, 50 concurrency, sync_writes = true)
• Hybrid search throughput: >186 ops/sec

For most single-product use cases, a single node on a $20–40/month VPS is sufficient.

Signals you need multi-node

Signal	Explanation
Write throughput saturated	Single node can’t keep up with ingestion rate
RAM pressure	HNSW index growing beyond available RAM
Zero-downtime requirement	You need HA failover; single node has none
Multi-tenant isolation	Separate data planes per customer

What multi-node adds (Business — Coming soon)

None of the following ships in the Community Edition today. Horizontal sharding, replication, HA failover, the management backoffice, and enterprise auth are all part of the planned Business Edition “Multi-Node” offering, coming soon:

• Horizontal sharding — memories are distributed across nodes by consistent hashing
• Replication — each shard has N replicas; writes are durable if any replica acknowledges
• HA failover — leader election per shard; surviving replicas elect a new leader on failure
• Centralised management — a web-based Backoffice admin UI manages all nodes, handles rebalancing
• Enterprise auth — SSO/SAML, per-team API keys, audit logs
• Observability — Prometheus/Grafana monitoring across the cluster

Upgrade path

Multi-Node is Business — Coming soon. Join the waitlist to be notified when it’s available.

When it ships, the upgrade path will be:

1. Stand up N additional nodes
2. Point them at the management backoffice
3. Trigger a rebalance — the backoffice migrates shards automatically
4. Update your clients to the cluster endpoint (the API is the same)

Your existing single-node data migrates without downtime.