Why we put the whole backend in one process
The multi-service AI stack is an energy and cost problem. Consolidation is our sustainability strategy — here's the reasoning.
Every production AI application today runs on a stack that looks like this: Pinecone for vectors, Neo4j for graph, Postgres for relational, LangChain to glue it together, LangSmith for tracing, Redis for cache, Auth0 for identity, Elasticsearch for search, and Airflow or Temporal for workflows.
Each of those services runs on separate infrastructure — separate servers, 24/7, even when idle; separate redundancy; separate network hops between them. Answering a single RAG query can cross four to eight service boundaries.
This is not a software architecture problem. It is an energy and cost problem. Running 8–12 services to answer one query is not commercially sustainable at the scale AI adoption demands.
The Purple8 answer
One process. One binary. One port. Everything in-process.
This isn't about being clever — it's the only architecture that makes AI commercially viable at global scale. The same engine that stores your data serves your vector search, runs your graph algorithms, orchestrates your workflows, and enforces your auth.
Bounded memory is a sustainability property
Purple8's bounded memory management means the same backend that ingests 2M nodes can ingest 20M nodes on the same hardware. The corpus grows; the machine does not. That is what makes AI affordable for teams that can't re-provision every time their knowledge base doubles.
More on the memory model in a future post.