Spice.ai OSS

A single-binary SQL engine in Rust, built on DataFusion and Arrow, that federates queries across databases, warehouses and lakes, keeps hot datasets in a local accelerated copy, and adds search and LLM APIs on top.

What it is: Query engines
Type: Open source
Made by: Spice AI, Inc.
License: Apache 2.0
Facts checked: 6 October 2026

What it is

Spice runs as one Rust binary (spiced) next to an application, as a sidecar, a standalone service or a cluster. You list datasets in a YAML file, spicepod.yaml: a PostgreSQL table, Parquet files in S3, an Iceberg catalog, a Databricks or Snowflake table, and so on from about 30 connectors. Applications then query them all with SQL over HTTP, Arrow Flight SQL, JDBC, ODBC or ADBC. Apache DataFusion, which works on Apache Arrow’s in-memory columnar format, plans and runs the queries. For a dataset left in place, Spice pushes as much of the query as it can down to the source. That keeps the data where it is, but the slowest source sets the latency of a join.

The main idea is acceleration. For any dataset you can turn on a local copy, held in memory as Arrow, in an embedded DuckDB or SQLite file, or in Spice Cayenne, its own engine built on the Vortex columnar format. Spice keeps that copy fresh by reloading it on a schedule (full), appending new rows (append) or applying change data capture (changes). It reads the PostgreSQL write-ahead log, the MySQL binlog, MongoDB change streams or DynamoDB Streams directly, with no Kafka or Debezium in between. Queries then hit the local copy instead of the source, and a results cache answers repeated queries from memory. The project describes this as an active cache, or a CDN for databases.

On top of the data it adds AI features: an OpenAI-compatible API in front of hosted or local models, embeddings, vector, full-text and hybrid search as SQL table functions, text-to-SQL, and a Model Context Protocol (MCP) server. Version 1.0 was declared stable in January 2025 and 2.0 in June 2026, which made distributed queries on Apache Ballista and the Cayenne accelerator generally available; v2.3.2 came out in September 2026. The runtime is Apache 2.0. Spice AI, Inc. builds it and sells Spice Cloud, a managed service, and Spice.ai Enterprise, and a few connectors (ODBC, ScyllaDB, NFS, Elasticsearch) ship only in Enterprise builds unless you compile them in yourself.

Why teams pick it

One SQL endpoint over many sources, with query push-down, so an application doesn’t need a driver and a pipeline per database
Hot data served from a local copy next to the app, in memory or on disk, kept fresh by refreshes or direct CDC from PostgreSQL, MySQL, MongoDB or DynamoDB
Small enough to run one instance per application or tenant: a single binary of about 140 MB, configured in one YAML file
Retrieval, search and LLM calls in the same engine as the data, through OpenAI-compatible and MCP interfaces

Watch out for

Uneven maturity: core connectors are stable, but Kafka, Spark and SQL Server are beta, GCS and ClickHouse alpha, the SQLite accelerator a release candidate, and the vector engines alpha
Accelerated copies need memory or disk (the docs suggest at least 1.5 times the dataset size), and if a source’s schema changes while Spice is running, refreshes fail until it restarts or schema detection is turned on
Federated joins across many sources slow down, since the slowest source bounds the query; the docs recommend accelerating such joins instead
A young, single-vendor project whose headline benchmarks (for example against DuckDB and Spark) are the company’s own

Alternatives

What all query engines have in common →

Amazon AthenaAWSAWS’s serverless SQL engine for data in S3: no cluster to run, and on-demand queries cost $5 per TB scanned.

Apache Arrow AceroExperimentalOpen sourceThe streaming execution engine inside Arrow’s C++ library: you hand it an exact plan of nodes (scan, filter, project, aggregate, join, sort) and it streams Arrow record batches through them, with no SQL parser or optimizer of its own.

Apache CalciteOpen sourceA Java framework with everything a database needs to understand a query (SQL parser, validator, relational algebra and a rule-based, cost-based optimizer) but no storage of its own, which Hive, Flink, Druid, Dremio, Beam and many other systems embed as their SQL front end and planner.

Apache DataFusionOpen sourceA query engine library in Rust, built on Arrow, that other projects embed and extend to build their own databases and data tools.+1 Apache DataFusion Comet

Apache HadoopOpen sourceThe project that made big-data clusters normal: a distributed file system (HDFS), a cluster scheduler (YARN) and the MapReduce engine.

Apache HiveOpen sourceThe first SQL engine for Hadoop, and the source of the Hive Metastore, the table catalog that Trino, Spark, Impala and Flink still read.Apache ImpalaOpen sourceAn MPP SQL engine in C++ for interactive queries over Hive tables on HDFS, Kudu, Iceberg and object storage; built and mainly sold by Cloudera.Apache PigDormantOpen sourceA step-by-step scripting language, Pig Latin, that compiles to MapReduce, Tez or Spark jobs on Hadoop. Still released, but the project calls itself dormant.

Apache SparkOpen sourceThe general-purpose distributed engine for large batch jobs, streaming and machine learning, in Python, SQL, Scala, Java or R.

Apache ZeppelinOpen sourceA self-hosted web notebook where each paragraph runs through an interpreter: Spark, Flink, JDBC, Python and more. Maintained, but behind Jupyter and Databricks in reach.

chDBOpen sourceThe ClickHouse engine packaged as a library: run ClickHouse SQL inside a Python, Go, Rust or Node.js program, with no server.

Cloudflare Basin SQLRenamedCommercialCloudflare’s serverless, distributed SQL engine for Apache Iceberg tables in Basin Catalog on R2, called R2 SQL until it became generally available on 1 October 2026, billed by the data it scans.

DuckDBOpen sourceAn in-process analytical SQL database: a library with no server that queries Parquet, CSV, Iceberg and S3 directly.

GizmoSQLOpen sourceA database server that wraps DuckDB (or SQLite) and serves it to many clients over Arrow Flight SQL, with TLS and authentication.

GlareDBDormantOpen sourceA small, embeddable SQL engine in Rust for querying Parquet and CSV files locally, over HTTP or in S3 and GCS, from a CLI, Python or the browser. It began as a DataFusion-based federated query service and was rewritten in 2025 on its own engine, and it has had no release since June 2025.

HotdataCommercialA managed SQL engine for AI agents, built in Rust on Apache DataFusion and Arrow: each agent gets short-lived “instant databases” to load data into, then runs read-only SQL, vector, full-text and geospatial queries over an HTTP API or CLI.

IbisOpen sourceA Python dataframe API that compiles to SQL, so the same code runs on DuckDB on a laptop and on BigQuery, Snowflake, PostgreSQL or more than 20 other engines.

PolarsOpen sourceA DataFrame library with a Rust query engine underneath: you write Python (or Rust, SQL, Node.js, R) and it plans, optimises and runs the query on every core, streaming data bigger than memory.

Presto (PrestoDB)Open sourceFacebook’s distributed SQL engine, now governed by the Linux Foundation, moving its workers from Java to C++ on Velox. Trino is its 2019 fork.

RayforceOpen sourceA small embeddable engine in pure C that runs columnar analytics, graph traversals and recursive Datalog queries in one optimised plan.

TrinoOpen sourceA distributed SQL engine that queries data where it lives, from Iceberg tables on S3 to a live PostgreSQL database, in one query.

VeloxOpen sourceMeta’s open-source C++ execution engine library: it takes an already-optimized query plan and runs it with vectorized operators, and it is the engine inside Presto’s C++ workers (Prestissimo) and Apache Gluten’s native Spark.

How it fits with other technologies

What Spice.ai OSS uses

What uses Spice.ai OSS

Tursois a query acceleration engine inSpice.ai OSSRelational databases

spicepod.yaml: accelerate Parquet files from S3, and replicate a PostgreSQL table by CDC · yaml

version: v1
kind: Spicepod
name: shop

datasets:
  - from: s3://acme-lake/events/2026/
    name: events
    params:
      file_format: parquet
    acceleration:
      enabled: true            # in-memory Arrow by default

  - from: postgres:public.orders
    name: orders
    params:
      pg_connection_string: postgresql://spice:${secrets:pg_pass}@db.internal:5432/shop
    acceleration:
      enabled: true
      engine: duckdb
      refresh_mode: changes    # stream the PostgreSQL WAL
      primary_key: id
      on_conflict:
        id: upsert

See it in a real stack

No architecture uses Spice.ai OSS yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2021–2026

Luke Kim and Phillip LeBlanc, who had built developer tools at Microsoft and GitHub, founded Spice AI in 2021. Kim said that while at Microsoft he had become convinced decision-making AI would matter to many applications, yet developers had no platform for it. The first Spice.ai, released as an alpha in August 2021, was an “open source runtime and distribution system for time series AI”: a runtime written in Go and Python that learned from streams of time-series data and served recommendations to apps over HTTP.

In February 2024, with version 0.7, the company replaced it with an all-new implementation in Rust. The new runtime dropped the built-in AI training engine and dashboard, which moved to the hosted Spice.ai platform, and became a SQL engine instead: Apache DataFusion for queries, plus local acceleration of datasets in Arrow or DuckDB. The company introduced it publicly in March 2024 as a SQL query engine to materialize and accelerate data from any database, warehouse or lake.

Over 2024 the project added search, model serving and an OpenAI-compatible API, and declared version 1.0 stable in January 2025, citing production use at Twilio and Barracuda Networks. Spice 2.0, in June 2026, moved beyond a single node with distributed queries on Apache Ballista, made the Vortex-based Cayenne accelerator generally available, and added direct CDC replication from operational databases.

Why it’s built this way

Build on DataFusion instead of writing a query engine: The Rust rewrite embedded Apache DataFusion from its first release (v0.7) for fast, standards-based SQL across sources. The company could then spend its effort on connectors, acceleration and AI features rather than on a planner and executor.
Materialize the working set next to the application: Engines such as Trino and Dremio run as central clusters that many applications share. Spice usually runs one instance per application or tenant and keeps the data that app uses locally, trading extra copies for lower latency and less load on the source systems.
Let each dataset pick its accelerator: No single storage engine suits every workload, so a dataset can use Arrow, DuckDB or Cayenne for analytical scans, or SQLite for transactional-style lookups, all behind the same SQL interface.
Drop model training from the open-source runtime: The 2021 runtime bundled its own training engine. Version 0.7 removed it and the dashboard, leaving those to the hosted platform, so the open-source engine could focus on serving data to applications and models.

Timeline

2021
Spice AI founded; first alpha of a Go and Python runtime for time-series AI in August
2024
Version 0.7 rewrites the runtime in Rust on DataFusion, in February
2025
Version 1.0 declared stable in January
2026
Version 2.0 in June: distributed queries on Ballista, Cayenne generally available, direct CDC

Sources10 · facts checked 6 October 2026

Improve this page on GitHub