Docstore can scale, but the important idea is this: the current single-VPS production shape is a solid early product foundation, not the forever architecture. The right path is staged hardening, workload separation, and operational maturity — not a panicked rewrite.
Yes. The underlying direction is sound: Postgres, pgvector, object storage, async ingestion, and separate bot/voice execution planes are all reasonable building blocks.
The current one-box deployment. The first limits will likely be database pressure, worker contention, retrieval latency, and noisy-neighbor effects.
No. The smarter path is staged infra and product hardening: observability, queue isolation, retrieval tuning, and cleaner workload separation.
Postgres + pgvector can go surprisingly far, but more chunks, more embeddings, and more concurrent retrieval will eventually push CPU, memory, index size, and maintenance overhead.
Heavy extraction, embeddings, connector sync, reports, and chat-adjacent background tasks should not all compete in one undifferentiated worker pool forever.
One big tenant with massive syncs or lots of traffic can distort everyone else’s experience unless we add queue isolation, limits, and fairness controls.
Run multiple app instances behind a proper load balancer instead of assuming one gunicorn node is enough.
Stay on Postgres + pgvector if it still performs, but be willing to isolate retrieval-heavy concerns or tune indexes/table layouts aggressively.
Add quotas, tenant-aware scheduling, usage analytics, and stronger admission control so growth stays predictable instead of chaotic.
Keep shipping product features, but add observability, queue visibility, and database performance checks so scaling conversations are grounded in data.
Split worker roles, improve tenant fairness, and strengthen retrieval performance before traffic makes those decisions for us.
Scale out app nodes, harden storage, and introduce stronger quota/isolation controls as the customer base and corpus size justify it.