Scaling & performance
EntityFlow is engineered to stay responsive as diagrams and teams grow. It targets two SLO milestones:
| Milestone | Tables | Concurrent editors | Status |
|---|---|---|---|
| B | ~500 | ~15 | Met |
| C | ~3,000 | 25+ | Target |
How the editor stays fast
The canvas keeps interaction smooth at scale through several techniques working together:
- Viewport virtualization — only what's on screen is rendered.
- Levels of detail — tables degrade gracefully as you zoom out: full → header → box → dot.
- Quadtree culling — spatial indexing skips off-screen geometry cheaply.
- Throttled presence — cursor and selection updates are rate-limited so a busy room doesn't flood clients.
How persistence stays cheap
- Debounced writes — CRDT updates are batched before hitting the database (see
EF_COLLAB_DEBOUNCE_MSin the Configuration reference). - Incremental projection — only changed entities are re-projected, never the whole diagram.
Running multiple server nodes
A single node serves a substantial workload on its own and needs no Redis.
To run more than one server replica, enable Redis fan-out so awareness (presence) and document updates propagate across all pods:
export EF_REALTIME_REDIS_ENABLED=true
export EF_REALTIME_REDIS_URL="redis://redis:6379"
This is required whenever you run more than one replica — without shared awareness, nodes diverge and editors on different pods see inconsistent state.
warning
On Kubernetes, the Helm chart enforces this: replicaCount > 1 requires redis.enabled=true or the chart fails to render. See Kubernetes & Helm.
Single-node deployments should leave Redis disabled.