Bottom Line
Vertiva's foundation owns its own data plane, its own models, and its own retrieval — capable of ingesting millions of documents from any source, running inference and vector search at GPU scale, and deploying into shared SaaS or a customer's own enterprise cloud platform (BYOC).
A Foundation Built to Evolve with New Technologies
| Interface Seam | Foundation | Scaling Target | Unlocks |
|---|---|---|---|
| Message broker | SQS | Kafka + Debezium CDC | Enterprise event volume, database change capture |
| Document parsing & ingestion | Single-node | Ray on Databricks + Delta Lakehouse | Millions of documents, distributed processing |
| Model & embedding client | Managed cloud AI (Bedrock) | Self-hosted (Kronk + vLLM) via model gateway | GPU-scale inference, cost control, data sovereignty |
| Knowledge base / vector store | Managed KB + S3 vectors | Qdrant HA cluster | Customer-selectable models, sharded high-availability search |
| Query routing | Single engine | Federated fan-out (semantic + lexical + graph) | Broader, higher-quality answers at scale |
No interface changes, no rework of existing contracts — just new implementations dropped behind the seams the foundation already exposes.
Owning the Data Plane, Ingesting at Enterprise Volume
The scaling program's data plane replaces the platform's single-node ingestion path with a distributed, governed pipeline: Kafka (MSK) for cross-service events, Debezium for database change-data-capture, and a Ray-on-Databricks compute engine writing into a medallion-structured Delta Lakehouse. On top of that sits a pluggable connector framework — the S3 drop-zone is the zero-integration default, with Google Drive, SharePoint/OneDrive, Slack, and database CDC landing through the same governed path — so "drop your data and it's searchable" holds true regardless of source or volume. The design explicitly targets ingesting millions of documents automatically, with a standardized, governance-aligned storage layout so every new source inherits the same access-control and lifecycle rules rather than requiring bespoke handling.
Owning Inference and Retrieval at GPU Scale
The self-hosted inference phase stands up dedicated GPU infrastructure, a Go-embedded inference path for high-throughput, low-latency small-model work, and GPU-served large-model generation with autoscaling and batching, all fronted by a single model gateway with routing and failover. Qdrant runs as a high-availability, sharded cluster with snapshots and backups as the platform's primary vector store, and each customer can select its own generation, embedding, and rerank models independently across multiple tiers — from a platform-curated catalog up to bringing their own weights. Retrieval itself scales out again in the federated search phase, fanning a single query across semantic, lexical, and graph engines and fusing the results, rather than relying on any single retrieval method to carry enterprise-scale answer quality.
Every Core Service Is Held to the Same Enterprise Bar
Scaling work is treated as infrastructure work, not feature work — so every decision, without exception, must prove the same set of properties before it is considered done:
- Scalability: a horizontal scale-out path load-tested to a stated throughput or volume target, with autoscaling policies and no single-node bottleneck.
- Resilience: graceful degradation with a defined fallback (e.g., self-hosted inference falling back to a managed provider), retries, circuit breakers, backpressure, and dead-letter/replay handling, chaos-tested before shipping.
- Migration safety: every swap follows dual-run → backfill → parity-evaluation → cutover, with a reversible rollback path and zero-downtime migration — the live platform keeps serving users the entire time.
- Security & multi-tenancy: tenant isolation, least-privilege access, and the platform's trust/classification model are carried through every new component, not re-derived from scratch.
- Cost: a cost model and per-tenant attribution for the new infrastructure, measured against the managed service it replaced.
This is the mechanism that keeps scaling incremental and low-risk: each new capability runs alongside the old one, is validated against production traffic, and is only cut over on formal acceptance — never a big-bang replacement.
Flexible Deployment for Every Enterprise Environment
Because scale means more than raw throughput for an enterprise buyer, the platform supports three deployment models without divergent code paths: shared multi-tenant SaaS, dedicated single-tenant, and customer-cloud (BYOC), where the platform is deployed directly into the customer's own cloud account. The data-residency requirements of regulated customers push dedicated/BYOC toward becoming the enterprise default, and the underlying storage and policy grammar is identical across all three models — so a deployment-model decision is a provisioning choice, not an architecture change.