Spice serves as the data substrate for multi-tenant AI agents, giving each tenant real-time access to its own data sources with configurable isolation and no per-tenant ETL pipelines. A lightweight Rust runtime can be deployed once for all tenants, once per tenant, or in a hybrid topology, and every deployment exposes the same SQL, search, and AI inference APIs over HTTP, Arrow Flight, FlightSQL, ODBC, JDBC, and ADBC.
Pipeline-per-integration architectures collapse at scale: every tenant brings its own schema, refresh cadence, and ownership, and ETL orchestration becomes the bottleneck. Spice federates queries across 30+ data sources and accelerates them locally, so adding a tenant is a Spicepod configuration change rather than a new pipeline.
spicepod.yaml manifest defines datasets, models, secrets, and acceleration behavior, so tenant topology is version-controlled and auditable.Four patterns trade off operational simplicity against isolation strength. Most SaaS workloads converge on a hybrid configuration.
One runtime serves many tenants. Datasets reference tenant-partitioned tables, and the application includes a tenant filter in every query.
This is the simplest and cheapest pattern to operate, but isolation is logical: correctness depends on every query path applying the tenant filter.
View-based variant: Move tenant filtering into the Spicepod using views, so agents query a tenant-specific view rather than constructing the filter at runtime.
One runtime, but each tenant gets its own dataset entry. The manifest is typically generated from tenant-onboarding metadata.
Tenant boundaries are explicit in configuration and easier to audit, but the manifest grows with tenant count and reload time and memory planning become operational concerns at large scale.
Run a dedicated Spicepod per tenant and route requests using tenant context from auth or session claims. Each runtime has an independent manifest, compute envelope, and cache.
This gives the clearest isolation model and per-tenant operational control, at the cost of higher operational overhead as tenant count grows. It fits regulated workloads that require strict data boundaries.
Large tenants run on dedicated Spicepods while the long tail shares a partitioned deployment. A tenant-aware router decides placement and clients query a single logical interface.
Hybrid isolation keeps the query interface stable while allowing tenant placement by policy, isolating high-load or regulated tenants on dedicated runtimes and using shared capacity for the long tail. It is the recommended starting point for variable SaaS workloads.
The right shape depends on isolation requirements, tenant count, and query volume per tenant.
| Requirement | Recommended Pattern |
|---|---|
| Small tenant count, uniform workload | Pattern 1 or 1-view |
| Explicit config-level boundaries, auditable manifest | Pattern 2 |
| Regulated tenants, strict per-tenant SLOs | Pattern 3 |
| Power-law tenant distribution | Pattern 4 (hybrid) |