Edge to cloud deployments: sidecar, microservice, and cluster
Spice runs as a single binary, a container, a Kubernetes workload, or a managed service on the Spice Cloud Platform. Every option runs the same runtime and reads the same Spicepod format, so teams pick the architecture that matches their latency, scale, and governance needs.
Do more with your data
Consolidate operational, analytical, and object store data into a governed and accelerated SQL query engine.
100x
up to 100x faster queries
80%
up to 80% cost savings on data lakehouse spend
2x
increase in data reliability for critical workloads
Sidecar deployments
Deploy Spice as a sidecar next to your application, in the same Kubernetes pod or on the same host. When the two share a network namespace, as containers in one pod do, the application queries Spice over localhost and reads of accelerated data skip the network hop. Separate containers on a Docker bridge network connect through container networking instead. Sidecars fit real-time decision-making and embedded AI workloads. A sidecar keeps serving its accelerated datasets when a source becomes unreachable.
View the docs
Microservice deployments
Run Spice as an independent service, with one or more replicas behind a load balancer. Many applications query the same accelerated datasets through one endpoint, and the service scales separately from the applications that call it. Each replica holds its own accelerated copy.
View the docs
Tiered deployments
Combine sidecar and microservice patterns to support mixed access patterns. Separate critical-path workloads from less performance-sensitive tasks and optimize for both real-time responses and scalability across separate tiers.
View the docs
Managed cloud deployments
Deploy a Spicepod to the fully managed Spice Cloud Platform and connect a GitHub repository for continuous delivery. Spice Cloud runs and scales the infrastructure, so your team does not operate servers or clusters.
View the docs
Enterprise deployments
Spice.ai Enterprise runs clustered deployments on Kubernetes, with distributed query execution across nodes. The Spice.ai Enterprise Kubernetes Operator manages per-replica StatefulSets, automatic volume resizing, update strategies, and crashloop protection.
View the docs
Integrations across all of your data sources
Accelerate your data stack with a library of 40+ prebuilt connectors for the most common databases, warehouses, and file stores, from Databricks and S3 to MySQL and PostgreSQL.
Deployed in production
Run data-intensive workloads on a high-performance engine trusted by teams building real-time systems at scale.
“Spice opened the door to take these critical control-plane datasets and move them next to our services in the runtime path.”
Peter Janovsky
Software Architect, Twilio
100x
Faster queries
“It just spins up and works, which is really nice. The responsiveness is amazing, which is a huge gain for the customer.”
Darin Douglass
Principal Software Engineer, Barracuda
Learn how Barracuda gained 100x faster query responses and reduced costs 50% with Spice
“What I like the most about Spice is that it's very easy to collect data from different data sources, and I'm able to interact with this data and do everything in one place.”
Dustin Warner
Director of Software Engineering, NRC Health
FAQs
Answers to common questions about Spice deployment architectures.
Yes. Every option runs the same Spice runtime with SQL federation and acceleration and the same data connectors. Each option reads the same Spicepod format. The application sends the same SQL to a sidecar, a microservice, or a managed project.
Yes. The Spice Cloud Platform runs Spice as a managed service, so your team does not operate servers or clusters. You deploy a Spicepod and can connect a GitHub repository for continuous delivery. See Spice Cloud pricing for plan details.
Yes, for datasets that the sidecar accelerates locally. A failed refresh keeps the current accelerated data, so reads continue and the data gets older. To keep that data across a restart, use a file-mode acceleration. Datasets without acceleration still need the source or the cluster.
Yes. Sidecars and the cluster read Spicepod manifests in the same format. To move a dataset, point the sidecar dataset at the cluster with the Spice.ai data connector. The application keeps querying its local sidecar on localhost. Only the cluster then needs the credentials for that source.
Choose a Spice deployment architecture by where the query must run: next to the application, in a shared service, or across a cluster. The choice changes latency, resource use, and operations. It does not change application code.
| Architecture | Where Spice runs | Query path | Best fit |
|---|---|---|---|
| Sidecar | Same pod or host as each application instance | localhost when sharing a network namespace | Latency-critical reads, edge sites, per-instance isolation |
| Microservice | One or more replicas behind a load balancer | Network call inside the cluster or VPC | Many applications querying the same accelerated datasets |
| Tiered | Separate tiers for critical-path and shared workloads | localhost for hot paths, network for the rest | Mixed workloads with different latency and throughput targets |
| Cluster-sidecar | Sidecars next to applications, backed by a Spice cluster | localhost, with non-accelerated datasets read from the cluster | Large fleets that need local reads and distributed compute |
| Managed | Spice Cloud Platform | Network call to a managed endpoint | Teams that do not want to operate infrastructure |
| Enterprise | Clustered Spice.ai Enterprise on Kubernetes | Distributed query across nodes | Large datasets, high availability, and centralized governance |
The tradeoff between the sidecar and the microservice is the core decision. A sidecar removes the network hop, but every pod runs its own runtime and accelerated copy. A microservice shares one endpoint across applications, but every query adds a network call. Each microservice replica also holds its own accelerated copy.
The sidecar vs microservice comparison covers this tradeoff in depth. The sidecar pattern guide covers Kubernetes startup, readiness, and failure behavior.
The Spice deployment documentation has a step-by-step guide for each target:
- Binary or Docker container for local development, single hosts, and container pipelines.
- Kubernetes with the Spice Helm chart, including GitOps rollouts through Argo CD or Flux.
- AWS on Amazon EKS with the Helm chart, or on EC2 with CloudFormation or Terraform.
- Azure on AKS, Azure Container Apps, Azure Container Instances, or virtual machines.
- Google Cloud on GKE, Cloud Run, or Compute Engine.
- Spice Cloud Platform for fully managed deployments.
For self-hosted production clusters, the Spice.ai Enterprise Kubernetes Operator runs each replica as its own StatefulSet. It also resizes persistent volumes, supports rolling and blue-green updates, and can pause a workload that crashloops.
A cluster-sidecar deployment places a lightweight Spice sidecar next to each application and a Spice cluster behind them. The cluster ingests each source once. It runs large scans and joins with distributed query. Each dataset in the sidecar Spicepod sets where its queries run:
- Accelerated dataset with the default
on_zero_results: return_empty: the sidecar answers from its local acceleration over localhost. It does not forward a query for rows outside its working set. - Dataset without acceleration: the sidecar forwards each query that misses its results cache to the cluster over Arrow Flight and streams the results back.
- Accelerated dataset with
on_zero_results: use_source: the sidecar sends the query to the cluster when the local acceleration returns no rows. That fallback ignores the sidecar'srefresh_sqlfilter, so it can return rows outside the working set. A refresh filter is not an access boundary. Whenrefresh_sqllimits a sidecar to one tenant's rows, keep the defaulton_zero_results: return_empty.
Sidecar datasets read from the cluster through the Spice.ai data connector. Source systems see traffic from the cluster only, not from every application instance. In Spice.ai Enterprise, sidecars can start from acceleration snapshots that the cluster writes to object storage. The cluster-sidecar architecture post walks through the design.
See Spice in action
Walk through your use case with an engineer and see how Spice handles federation, acceleration, and AI integration for production workloads.
Talk to an engineer (opens in a new tab)