Spice is an open-source SQL query and AI compute engine, written in Rust, for data-driven apps and agents.
Spice provides four industry standard APIs in a lightweight, portable runtime (single ~140 MB binary):
Spice embeds DataFusion (opens in a new tab), the fastest single-node Parquet SQL query engine, and DuckDB (opens in a new tab), to serve secure, virtualized data views to data-intensive apps, AI, and agents.
For a developer-focused walkthrough of when and how to use Spice, see A Developer's Guide to Understanding Spice.ai (opens in a new tab).
Spice is primarily used for:
For example, deploy Spice as a sidecar alongside applications served by centralized platforms like Databricks or Snowflake, materializing hot datasets locally to reduce latency and offload query volume from the source.
Data-grounded AI anchors models in accurate, current, domain-specific data rather than relying solely on pre-trained knowledge. Spice unifies enterprise data across databases, data lakes, and APIs, dynamically incorporating real-world context at inference time. This helps minimize hallucinations, reduce operational risk, and build trust in AI by delivering reliable, relevant outputs.
Spice is purpose-built for data and AI applications and agents, designed with low-latency access, materialization, and proximity to applications. Trino/Presto and Dremio primarily target big data analytics and rely on centralized clusters. Spice's decentralized approach reduces latency, simplifies deployment, and improves efficiency.
Spark excels at distributed batch processing and large-scale transformations. Spice focuses on real-time, low-latency data access and AI inference. Spice materializes data locally and supports tiered storage, optimizing performance for applications requiring fast access and high concurrency.
Starting with v1.9 (preview), Spice also supports multi-node Distributed Query (opens in a new tab) execution based on Apache Ballista (opens in a new tab), splitting a single query across scheduler and executor nodes for partitioned data lake sources. This closes much of the gap with Spark for large analytical scans while keeping Spice's low-latency, materialization-first model for application and agent workloads. See Apache Ballista at Spice AI (opens in a new tab) for the architecture and Operationalizing Amazon S3 for AI (opens in a new tab) for a data-lake example.
DuckDB is an embedded analytics database optimized for OLAP queries. Spice integrates DuckDB for data acceleration, combining DuckDB's analytical capabilities with Spice's broader federation, multi-engine support, and flexible deployment. Spice can be considered an enterprise/production productization of DuckDB for data-intensive applications.
Yes. Spice natively supports federated queries across disparate data sources with advanced query push-down capabilities. Spice executes portions of queries directly on source databases, reducing data transfer and improving performance. Learn More (opens in a new tab).
Yes, but performance degrades as the number of sources and tables grows because the slowest source bounds end-to-end latency. For workloads that join across many tables or many heterogeneous sources, the recommended pattern is to materialize the join into an accelerated dataset or accelerated view (opens in a new tab). This converts a multi-source federated join into a single local scan, making latency predictable and decoupling query performance from any one source's availability.
Plan acceleration of hot joins proactively rather than waiting to discover them under load. See Query Federation (opens in a new tab), Data Acceleration (opens in a new tab), and Performance Tuning (opens in a new tab) for tradeoffs and configuration. The Multi-Tenancy for AI Agents without the Pipelines (opens in a new tab) blog post walks through a concrete federation + acceleration example.
Yes. Spice supports querying nested data through both native nested types (struct, list, map) and JSON-encoded text columns.
For nested types, use standard field access (e.g. column.field.subfield). For JSON-encoded text columns, Spice provides a family of JSON SQL functions (opens in a new tab) including json_get, json_get_str, json_get_int, json_get_float, json_get_bool, json_get_json, and json_get_array, plus the -> operator.
Spice pushes JSON predicates down to the underlying engine (e.g. DuckDB) where supported. When pushdown is not viable for a particular expression, Spice transparently evaluates the predicate in DataFusion (opens in a new tab) so queries always execute correctly. If a query against a nested field is unexpectedly slow or fails, prefer the typed json_get_* variants over generic extraction so the planner can reason about types.
Spice uses Apache DataFusion (opens in a new tab) as its primary query execution engine, providing vectorized, multi-threaded query processing with automatic memory management and spilling. DataFusion powers the Arrow and Spice Cayenne (Vortex) accelerators. Spice also supports DuckDB, SQLite, and PostgreSQL as acceleration engines. Developers can select engines based on workload requirements, balancing performance, concurrency, and latency.
See Performance Tuning (opens in a new tab) for sizing guidance and the Memory (opens in a new tab) reference for how Spice manages query memory and spilling under load. For deeper context, see How we use Apache DataFusion at Spice AI (opens in a new tab) and Vortex at Spice AI (opens in a new tab) on the Cayenne columnar format.
Not solely. Spice functions as an active cache or working dataset prefetcher. A working dataset is a subset of data actively used by an application or model, such as recent records or frequently accessed tables. Unlike traditional caches that fetch data reactively, Spice proactively prefetches and materializes data based on filters, intervals, triggers, or Change Data Capture (CDC), ensuring data readiness for queries. Spice also supports results caching (opens in a new tab).
Yes. Spice acts as a CDN for databases by loading and materializing datasets close to applications, reducing latency and improving query efficiency. Read more (opens in a new tab).
Yes. Spice accelerates data locally using Apache Arrow, Spice Cayenne (Vortex), DuckDB, SQLite, or PostgreSQL, enabling real-time analytics and sub-second query performance for data-intensive applications and dashboards.
Yes. Spice supports streaming ingestion from several sources:
INSERT/UPDATE/DELETE events to the accelerator with refresh_mode: changes.refresh_mode: append for real-time, append-only acceleration.For a real-world architecture using DynamoDB Streams to sync data to thousands of nodes, see Real-Time Control Plane Acceleration with DynamoDB Streams (opens in a new tab).
For sources with a monotonically-increasing version column (e.g. updated_at), Spice incrementally ingests new and modified records using time_column (opens in a new tab) + refresh_mode: append (opens in a new tab), with refresh_append_overlap (opens in a new tab) to tolerate clock skew and retention_period (opens in a new tab) to evict old or soft-deleted records. Pair with primary_key + on_conflict: upsert to deduplicate re-read rows within the overlap window. See Data Refresh (opens in a new tab) for configuration details and examples.
Spice provides several controls for tuning ingestion pressure:
refresh_mode: append (opens in a new tab) and a time_column (opens in a new tab) to fetch only new or changed rows instead of reloading the full dataset.max_concurrent_requests (shared per SQL Warehouse), and the GitHub connector (opens in a new tab) exposes github_max_concurrent_connections (shared per token / app installation). Most connectors also expose pool and timeout parameters.runtime.num_of_parallel_loading_at_start_up (opens in a new tab) to bound how many datasets initialize concurrently at startup.refresh_check_interval, refresh_jitter, and refresh_retry_* parameters in Data Refresh (opens in a new tab) — to spread load over time and avoid thundering-herd patterns.Lowering concurrency and increasing intervals reduces source load but increases the time required to reach steady-state freshness; tune iteratively against your source's RPS and concurrency limits. See Performance Tuning (opens in a new tab) and the Memory (opens in a new tab) reference for guidance on balancing throughput and resource usage.
Yes. Several patterns help avoid eagerly refreshing datasets that may never be queried:
ready_state: on_registration (opens in a new tab) — Spice marks the dataset ready before any data has been loaded, so the dataset is registered immediately and the first refresh is initiated lazily.POST /v1/datasets/:name/acceleration/refresh (opens in a new tab) endpoint to trigger a refresh from an external scheduler, webhook, or first-query signal.refresh_mode: caching (opens in a new tab), which fetches on first request and revalidates in the background.on_zero_results: use_source (opens in a new tab) so queries that miss the acceleration transparently fall through to the source.These patterns combine well in multi-tenant deployments where only a fraction of tenants are active at any given time. See Multi-Tenancy for AI Agents without the Pipelines (opens in a new tab) for a worked example.
Spice infers the schema for datasets and views at startup and does not apply runtime schema changes by default. If the source schema changes while the runtime is running (for example, columns are added, removed, or their types change), data refreshes will fail with a schema mismatch error rather than silently applying the new schema. This behavior is intentional — it protects against unintentional or breaking schema changes propagating into accelerated tables.
To pick up a new source schema, restart the Spice runtime. On startup, Spice re-infers the schema from the source, and the accelerated table is re-initialized with the updated schema.
Runtime schema evolution controls are planned for a future release but will remain off by default to guard against unexpected schema drift.
Spice provides unified APIs for data and AI workflows, including model inference, embeddings, and an AI gateway supporting OpenAI, Anthropic, xAI, and Nvidia NIMs. Spice includes advanced LLM tools such as vector and hybrid search, text-to-SQL, SQL retrieval, data sampling, and context formatting.
Spice supports local model serving (e.g., Llama3) and gateways to hosted AI platforms including OpenAI, Anthropic, xAI, and Nvidia NIMs. Learn More (opens in a new tab).
For most deployments, the recommended pattern is to embed in the central ingestion tier with GPU-equipped nodes: the embedding model runs once per row during ingestion, vectors are stored in the acceleration, and read-tier replicas access them via snapshots (opens in a new tab) or direct query. This minimizes data movement and keeps the read tier inexpensive to scale.
When embeddings must be computed at query time (e.g. user-supplied queries for vector search (opens in a new tab)), dedicated embedding instances co-located with the read tier — or a shared, horizontally-scaled embedding service — provide better latency than per-replica GPUs. See the Local (opens in a new tab) and Hugging Face (opens in a new tab) embedding component guides for sizing.
Spice supports vector search (opens in a new tab) and full-text search (opens in a new tab) over accelerated datasets. Vectors are stored in the acceleration alongside the source data, so search executes locally without round-tripping to a separate vector database.
For best performance, store accelerated vector datasets in file-mode DuckDB or Spice Cayenne (Vortex) — file-mode is often faster than in-memory due to columnar compression and dictionary encoding — and configure acceleration indexes (opens in a new tab) on filter columns to narrow brute-force scans. See Performance Tuning (opens in a new tab) and the Memory (opens in a new tab) reference for sizing accelerated vector workloads, and Vortex at Spice AI (opens in a new tab) for the storage format underpinning Cayenne. Expanded HNSW and other approximate-nearest-neighbor index types are tracked for future releases.
Spice exposes search through both an HTTP API and SQL table-valued functions:
POST /v1/search (opens in a new tab) — a unified HTTP endpoint that performs vector, full-text, multi-vector, and hybrid search across configured datasets. Requests specify the dataset(s), search text, optional filters, and limit; the response returns ranked rows with relevance scores and any requested passthrough columns. Embeddings are computed automatically when an embedding model is configured on the dataset.vector_search(table, 'query') and related functions can be composed with standard SQL JOIN, WHERE, and ORDER BY for hybrid filtering and ranking. See Vector Search (opens in a new tab) and Full-Text Search (opens in a new tab).For an end-to-end example, see the Search (opens in a new tab) overview and the Amazon S3 Vectors with Spice (opens in a new tab) blog post.
Spice supports multiple deployment configurations:
Spice Cloud Platform (SCP) provides managed, SOC 2 Type II compliant deployments. Learn More (opens in a new tab).
For moving a deployment to production, see the Production Readiness (opens in a new tab) guide and the Enterprise Distribution Comparison (opens in a new tab) for choosing between OSS and Enterprise distributions.
The sidecar model, cluster model, snapshot bootstrapping (opens in a new tab), and pointing instances at each other for tiered fallback are all open source. The Distributed Query (opens in a new tab) feature — splitting a single query across multiple scheduler/executor nodes (Apache Ballista) — is available as a preview starting in v1.9. The Spice.ai Enterprise (opens in a new tab) Kubernetes Operator additionally provides the SpicepodSet (opens in a new tab) and SpicepodCluster (opens in a new tab) CRDs for declarative replica management, automatic PVC resizing, mTLS, and scheduler/executor topology.
Distributed query is only required for large single-query workloads (TB/PB-scale scans, heavy embedding/indexing). See the Enterprise Distribution Comparison (opens in a new tab) for a feature-by-feature breakdown.
Reads fall through a layered chain. A request first checks the local sidecar's results cache and acceleration. On a miss, the request is delegated to the central cluster, which checks its own results cache and acceleration. If both miss, the cluster federates back to the original data source. The full chain is results cache → acceleration → federated source, applied at each tier.
For details, see the Sidecar (opens in a new tab), Cluster (opens in a new tab), and Tiered (opens in a new tab) architecture guides, along with Caching (opens in a new tab), Data Acceleration (opens in a new tab), and Query Federation (opens in a new tab). See the Cluster-Sidecar Architecture (opens in a new tab) blog post for a deeper walkthrough of the pattern.
Separate the ingestion (write) tier from the query (read) tier:
If the ingestion tier is temporarily unavailable, read replicas continue serving (potentially stale) data from snapshots, providing a recovery window measured in hours rather than minutes. The Enterprise SpicepodSet (opens in a new tab) resource manages replica sets declaratively with rolling/parallel update strategies, automatic PVC resizing, and crashloop protection. See Cluster (opens in a new tab) and the Cluster-Sidecar Architecture (opens in a new tab) blog post for the open-source pattern, and the Production Readiness (opens in a new tab) guide for HA checklists.
Shards are independent groups of Spice instances, each with its own Spicepod configuration. Strategies that scale well:
bucket(org_id, N)) instead of one partition per tenant. ACLs are still enforced at query time, and operational complexity is bounded by N rather than tenant count.SpicepodSet (opens in a new tab) (and SpicepodCluster (opens in a new tab) for distributed query) with rollout strategies, mTLS, and OIDC.See the Sharded (opens in a new tab) deployment architecture for guidance, and Multi-Tenancy for AI Agents without the Pipelines (opens in a new tab) for a multi-tenant blueprint.
Spice supports Kubernetes Secrets (opens in a new tab), AWS Secrets Manager (opens in a new tab), Azure Key Vault, environment variables (opens in a new tab), and the local OS keyring (opens in a new tab). See the secret stores overview (opens in a new tab) for configuration and selectors.
Additional secret backends — including HashiCorp Vault — are tracked as planned additions. Open or upvote an issue at github.com/spiceai/spiceai (opens in a new tab) to influence prioritization.
Spice provides secure, auditable data access through sandboxed runtimes, secure endpoint checks, and detailed telemetry and tracing. The Spice Cloud Platform (SCP) is SOC 2 Type II compliant, meeting enterprise security and compliance requirements. See the Production Readiness (opens in a new tab) guide for hardening recommendations.
Yes. Spice integrates with BI tools through standard SQL interfaces (ODBC, JDBC, Arrow Flight SQL), enabling accelerated, real-time analytics for dashboards and reporting. An official Tableau Connector (opens in a new tab) is available and a BI Acceleration (opens in a new tab) demo using Apache Superset.
The Spice.ai Cookbook (opens in a new tab) provides over 65 quickstarts and examples demonstrating Spice capabilities, including federated queries, RAG, text-to-SQL, and more.
Visit the Spice.ai Getting Started Guide (opens in a new tab) to install Spice, connect data sources, and begin querying. Spice installs the GPU-accelerated runtime by default (if supported).
Developers can contribute by submitting code, documentation, or raising issues on GitHub (opens in a new tab). See CONTRIBUTING.md (opens in a new tab) for guidelines.