Spice 2.0: Real-Time Analytical Query on Operational Data, Without ETL

AI agents that need real-time data are driving new, demanding, analytical workloads on operational databases.

However, analytical queries on stores like MySQL, PostgreSQL, and MongoDB risk disrupting mission-critical operations with heavy execution, complex RLS-policies, and data-leakage. ETL pipelines that copy data from operational to analytical systems are expensive, costly to operate, and are not real-time, typically with stale data in the hours or even days.

With Spice 2.0, organizations can add sandboxed analytics replicas alongside their operational databases in minutes with sub-second query and real-time freshness, using high-throughput replication.

And when the data outgrows one node, deploy petabyte-scale compute with confidence. Multi-node, multi-active, highly available distributed query built on Apache Ballista is now generally available.

What's New in Spice 2.x

High-Throughput Change-Data-Capture (CDC) Replication. Bolt high-performance analytics-ready replicas onto live operational databases. Spice replicates directly from the PostgreSQL WAL, MySQL binlog, and MongoDB oplog without pipelines or query load on production. It's incrementally adoptable: start with a single table and be running analytical queries on operational data in minutes with 2-second end-to-end freshness under continuous ingest. v2.1 adds an in-memory CDC tier and a dedicated compaction runtime that cut replication lag on high-volume workloads, plus shared PostgreSQL replication slots across changes-mode datasets.

Multi-Node Distributed Compute. Petabyte-scale compute built on Apache Ballista is now generally available. Object-store native and highly available, with multi-active schedulers and no single point of failure. Three executors run TPC-H SF100 2.9x faster than one node. v2.1 distributes Iceberg catalog table scans and broadcast-joins small dimension tables, with shared scheduler job state and failover.

Spice Cayenne. The premier Spice acceleration engine built on Vortex is now generally available: 1.5x faster than DuckDB with 3x less steady-state memory, and 26x faster than Spice 1.x on TPC-DS SF100 - now with atomic WAL-staged writes, high-throughput ingestion, MERGE INTO, and SQL-defined partitioning. v2.1 adds experimental adaptive self-tuning that adapts Cayenne to hardware, schema, and live workload.

Spice Kubernetes Operator. Full lifecycle management and control for running Spice at scale on Kubernetes with blue/green deployments, instant-rollback, and data-aware routing.

Enterprise Security & Policy. OIDC authentication, a Cedar policy engine, PII masking, and mTLS, all enforced before data reaches the agent.

And More! Searchable Tool Registry, SQL & WASM user-defined functions (UDFs), DataFusion v54, and new data connectors including Elasticsearch and Azure Cosmos DB.

Benchmarks: 1.5 - 1.8x faster than Spice 1.x on TPC-H SF100 with up to 42% less memory · 26x faster on TPC-DS SF100 with Cayenne · ~170x faster CDC ingest than 1.x · 2.9x faster distributed query from one node to three · 2-second CDC freshness · 1,046 QPH of CH-BenCHmark analytics at SF1000 under a 266,000+ tpmC live transactional load - full results below.

Launch a managed cluster on Spice Cloud or try Spice 2.0 OSS.

Spice 1.0-Stable shipped in January 2025 purpose-built for agentic workloads, so that AI agents could be grounded in enterprise data. Spice 1.0 packaged the core building blocks for AI apps into a single runtime; query federation and acceleration, hybrid search, and integrated LLM inference, all delivered by a single SQL endpoint. This lightweight, 140MB single-node engine, built on Apache DataFusion, in Rust, excelled at fast, low-latency reads on real-time operational data, and Barracuda runs it in production at global scale.

Figure 1: The Spice platform and features.

However, as enterprise agents were deployed, they demanded even more:

• Freshness. An agent acting on stale data and generating incorrect answers or inputs to a decision can be disastrous for a business.

• Scale. An agent without all relevant context has gaps in its knowledge. Agents need to query and search across both real-time data and multi-terabyte to petabyte-scale historical datasets.

• Enterprise Controls. Enterprise agents demand highly-available deployments, secure mTLS and OIDC authentication, RBAC and ABAC authorization, and policy-defined row and column level filtering and PII masking.

The Spice 2.0 platform delivers real-time, single-digit second data freshness, query and search at petabyte-scale, all with enterprise-grade operations and control.

You can now add analytical query and search to your operational data, without ETL, via high-throughput CDC replication. Query petabytes with Apache Ballista-based multi-node distributed compute, and deploy at enterprise-scale with the new Spice Kubernetes Operator and enterprise controls.

All this continued to be built on the open-source Spice engine, written in Rust on open-standards, including full support for Arrow, Iceberg, Delta, Parquet, and Vortex.

Add Spice to your operational data today!

Performance

Spice 2.0 numbers are measured on release-candidate builds; Spice 1.x numbers on the final 1.x release (v1.11.6) - identical harness, hardware, and benchmark specs throughout. Cluster benchmarks ran on i3.4xlarge nodes (16 vCPU, 122 GB RAM) in AWS; single-node benchmarks ran under a 256 GB memory limit.

Analytics on live operational data: CH-BenCHmark

CH-BenCHmark is the classic HTAP (hybrid transactional/analytical processing) benchmark: it runs the TPC-C transactional workload and TPC-H-style analytical queries concurrently, against the same data. Benchmarks like TPC-H measure analytics on data at rest; CH-BenCHmark measures the scenario Spice 2.0 is built for - analytical queries that stay fast and correct while transactions continuously change the data underneath them.

The benchmark configuration mirrors the 2.0 architecture end-to-end: PostgreSQL serves the TPC-C transactional workload, a single Spice node replicates committed changes via CDC into Cayenne acceleration, and analytical queries run against the Spice replica - production never sees the analytical load. Scale factor 1000: 1,000 warehouses and 300M+ rows, with a 600-second measurement window on a single 64-core node.

PostgreSQL sustained roughly 10,000 transactions per second for the full window while Spice served the entire analytical workload from the replica.

Operational freshness under load

Spicebench measures the full operational loop on TPC-H SF10: continuous ingest, concurrent query load, and checkpoint validation until queries return exactly-correct results. End-to-end freshness - from ingest to exactly-correct results - is single-digit seconds in both modes: 2.0 s for CDC (inserts + updates + deletes) and 7 s for append streams.

Spice 2.0 vs. Spice 1.x: same hardware, same data

Durations are wall-clock for the full query suite. The 26x TPC-DS result is real, not rounding: a pathological join query that took 65 minutes on 1.x completes in 5.3 seconds on 2.0. And Spice 2.0 with Cayenne - 88.3 s on TPC-H SF100 - is the fastest configuration in the entire launch benchmark matrix.

Distributed query: near-linear scaling

TPC-H SF100 executed directly against federated S3 Parquet - no local acceleration - comparing one node to a three-executor Ballista cluster over the same source.

Workloads are derived from the TPC-H, TPC-DS, CH-BenCHmark, and ClickBench specifications; results are not audited TPC results.

Early feedback on 2.0

Here's what teams at Barracuda and Summation had to say about migrating workloads to 2.0:

Barracuda Networks - Spice Cayenne acceleration for email archive search

Barracuda uses Spice to modernize data access for its email archiving and audit log systems, where queries were slow and costly. Before Spice, customers searching email archives faced delays of up to two minutes because of the volume of data being scanned. With 2.0, Barracuda migrated from DuckDB to Spice Cayenne acceleration, unlocking faster queries at higher scale and lower memory usage.

By migrating from DuckDB to Spice Cayenne, we solved our last mile query optimization problem where data layout and pruning alone weren't sufficient and achieved real-time query performance over a petabyte-scale, frequently-updated Delta Lake table.

Kevin Haggard

Vice President of Engineering

Summation - Unified AI-driven decision platform

Summation is an AI-driven decision platform that integrates financial and operational data into a single governed model. Since every customer runs a different stack, the Summation platform has to easily onboard and query disparate enterprise data sources.

Spice is the data plane behind Summation. Every connector we ship, from Snowflake to a generic REST-as-a-table, collapses into one SQL surface, which is what makes our AI agents portable across a customer's stack. 2.0's distributed query takes the scaling concern off the table.

Ramachandra Ramarathinam

CTO

Spice 2.0 in Depth

High-Throughput Change-Data-Capture (CDC) Replication

Figure 2: Agent-native CDC replication.

Spice 2.0 introduces first-class CDC replication, so you can add Spice as an analytical node to query live operational data without building pipelines. Point Spice at an operational database, and it replicates changes, without query load on production. It's incrementally adoptable and composable; start with one store or table, replicate changes to Spice datasets, and even execute joins across them.

Spice supports two modes of replication:

• Change Data Capture (CDC). Writes and deletes land in the operational store; committed changes are replicated from the native change log.
• Event stream. Append-only data is consumed from streaming systems like Kafka with upsert semantics.

Spice ships native replication, without requiring Debezium or an external streaming layer. Native support includes PostgreSQL WAL logical replication, with automatic slot management and bootstrapped snapshot, MySQL binlog replication, MongoDB Streams oplog, and DynamoDB Streams. Debezium support is improved and additional native sources are on the roadmap.

Native replication is also what makes bootstrap fast: on CH-BenCHmark SF1000, Spice snapshotted a 300M-row PostgreSQL table in ~9 minutes at ~566K rows/s - roughly 170x the ingest rate of the 1.x Debezium-based path.

Multi-Node Distributed Compute built on Apache Ballista

Figure 3: Multi-node distributed cluster roles in Spice 2.0.

2.0 brings the general availability of petabyte-scale, high-availability, multi-node compute. Powered by Apache Ballista, it distributes scans, joins, aggregations, and LLM inference across fleets of executor nodes.

Multi-node, distributed query supports two modes. Synchronous query for interactive workflows requiring fast, low-latency query and asynchronous query for long-running analytical and batch jobs. The scheduler distributes work dynamically as executors join or leave the cluster, routes partition-aware queries to the appropriate executors, and uses NDV-aware table statistics so large semi-joins size correctly instead of running out of memory.

Spice Distributed Query supports:

• Highly-available, object-store native schedulers with no single point of failure; any scheduler can schedule or resume any query
• mTLS encryption across all inter-node communication by default
• Spice Kubernetes Operator for highly-available, data-aware blue-green deployments, zero-downtime rolling upgrades, health checks, and Prometheus metrics
• Synchronous and asynchronous execution modes; async results materialize to object storage
• Dynamic cluster sizing as executors join or leave

With Spice, you get distributed compute with local acceleration, hybrid search, and AI inference in a single object-store native platform. No JVM, no Zookeeper, just a high-performance Rust runtime and object-store.

Check out the live demo, where Phillip queries a 100M-row dataset, reducing a 22 second single node query to 2.4 seconds scaling across a multi-node Spice cluster with Cayenne acceleration:

Cluster-Sidecar Architecture

Figure 4: Cluster-sidecar architecture for scale and locality.

The new multi-cluster support enables new workload-optimized architectures. The cluster-sidecar architecture combines a Spice multi-node cluster for scale and lightweight sidecars for locality, so agentic workloads get both fast, low-latency query of hot data and fast, distributed query across petabyte scale data lakes.

In this pattern, Single-node Spice instances run co-located with applications, materializing only the working set that application or AI agent requires. When a sidecar needs to reach beyond its local working set or run heavy long-running queries, it delegates to the cluster.

The tiers collaborate rather than just stack. The multi-node cluster handles ingestion, replication, shared accelerations, while each sidecar stays light and specific to its agent or dashboard, serving and caching the working set it needs.

The sidecar acts as a physically isolated sandbox of working data, while Spice manages refreshing data and delegating queries to the cluster replicas instead of the production database, so analytical queries and agents never contend with the operational workload.

Spice Cayenne (GA)

Figure 5: Spice Cayenne architecture.

Spice Cayenne was introduced in preview in v1.9 as Spice's next-generation data accelerator and reaches general availability in 2.0.

It's built on Vortex, an open-source columnar format (Linux Foundation, Apache-licensed) designed for the access patterns of agents: random access, point lookups, concurrent readers, and streaming updates (unlike Parquet's batch analytics focus). Cayenne pairs a Vortex data layer with an embedded metadata engine, which supports terabyte-scale workloads with significantly lower memory requirements than DuckDB.

With 2.0, Cayenne now supports high-throughput ingestion of writes, changes, and deletes beyond its append-optimized initial release. Writes are staged through a write-ahead log and commit atomically with full ACID semantics. Small writes are absorbed by a low-latency inline/mem-tier and are immediately queryable.

For CDC, primary-key DELETEs that identify keys directly skip the table scan, updates use merge-on-read position deletes instead of rewriting the table, and a dedicated compaction runtime keeps that background work off the query and ingest. MERGE INTO plus SQL-defined (PARTITION BY) and composite partitioning round out the SQL surface.

Production characteristics:

• 1.57x faster than DuckDB on TPC-H SF100 (88.3 s vs. 138.3 s) - the fastest configuration in the 2.0 launch benchmark matrix
• 26x faster than Spice 1.x on TPC-DS SF100
• 1,025 QPH of CH-BenCHmark analytics at SF1000 while continuously ingesting CDC changes from a PostgreSQL source running at 265,968 tpmC
• 3.6x lower steady-state (median) memory than DuckDB on TPC-H and ClickBench, 2.9x lower on TPC-DS
• Matches DuckDB query performance on ClickBench with 21% lower peak memory and a 34% smaller on-disk footprint
• 100x faster random access compared to Parquet
• 10-20x faster full scans compared to Parquet

Spice Kubernetes Operator

The Spice Kubernetes Operator v1.0 is now generally available to enterprise customers. It manages the full data-aware deployment lifecycle, on cloud or on-premises, for running Spice at scale on Kubernetes.

Two Custom Resource Definitions (CRDs) are included supporting multi-node clusters and single-node deployments. The SpicepodCluster CRD manages scheduler and executor nodes, mTLS certificate provisioning, rolling upgrades, and automatic failover. The SpicepodSet CRD manages single-node deployments and sidecars: injecting Spice instances into application pods via annotations, scaling them horizontally, and handling persistent storage when required.

Production characteristics:

• Automatic mTLS certificate provisioning across all cluster nodes
• Crashloop protection, instant rollback, and sidecar-injection via annotations
• Persistent volume management with automatic resizing
• Prometheus metrics via ServiceMonitor for existing observability stacks
• Network policy management and IRSA-compatible service account configuration

Enterprise Security & Control

Spice 2.0 includes the security and controls demanded by enterprises and new agentic workloads.

The Spice platform is secure-by-default with mTLS, OIDC authentication, and RBAC and ABAC authorization. Agent working sets of data are declaratively defined so each sandboxed Spice instance is only provisioned with data that any specific agent should access. Fine-grained policy to the row and column level can be defined and enforced by the Cedar policy engine, especially useful for defining specific data LLM tools or UDFs can access. Cedar policy is integrated and enforced in the core DataFusion query engine, with no ability to circumvent via SQL.

• Cedar-based Policy Engine (Beta). Defined-policy access control at query time, written in Cedar, the open authorization language developed by AWS. Per-principal row-level filtering and column masking are evaluated against the caller's identity through functions like current_principal(), so an agent or tool sees only the rows and columns its identity is authorized for, regardless of how the query is written.
• mTLS. Enforced across all inter-node and client communication, including HTTP and Arrow Flight, with hot-reloading certificates for zero-downtime rotation.
• Authentication (OIDC). Validates OIDC bearer tokens (JWTs) issued by enterprise identity providers including Microsoft Entra ID, Okta, Cognito, and Google, on runtime endpoints. Standalone or combined with API keys and native Secret Store integration.
• Secret Stores. New Native HashiCorp Vault and Azure Key Vault integrations in addition to AWS SecretStore and Kubernetes secrets. Read-only API key enforcement prevents write operations under restricted keys.
• Per-Principal Cache Namespacing. Each principal gets an isolated cache namespace, so accelerated working sets and results never cross identity boundaries.

The Spice Cloud Hybrid Model

Spice Cloud is a managed Spice service that operates cloud-hosted multi-node Spice clusters, including high-availability distributed query, Cayenne acceleration, search, and AI inference for you.

In a hybrid cluster-sidecar deployment, Spice Cloud manages the multi-node cluster while application sidecars can run in your own environment alongside your applications and agents. Heavy compute is delegated to the fully managed infrastructure. Latency-sensitive sidecar instances run wherever your applications and agents live, in your Kubernetes clusters, VPCs, on-premises data centers, or edge, and serve hot data locally at sub-second latency over mTLS.

What's next

We're already working on the next chapter of Spice: BYOC (bring-your-own-cloud), distributed search across multi-node clusters, write-back acceleration with full DML, an Iceberg-REST compatible Cayenne Catalog, webhooks and event-driven actions, and much more. The roadmap is public and community-driven.

The demands on data infrastructure keep growing as apps and agents demand real-time operational, analytical, streaming, and service data. From our founding in 2021 to the future, we're building Spice as the best data platform to power the next-generation of intelligent, AI-driven apps and agents.

Add Spice to your operational data. Analytical query with no ETL. It's open source, portable, scalable, and fast. Welcome to Spice 2.0.

If you're an architect or technical leader evaluating data infrastructure for AI agents in production, we'd love to talk. Mention this post when you reach out to hey@spice.ai, and the first 15 teams will receive a dedicated architecture workshop with our engineering team.

Start building

The fastest path to production is Spice Cloud. And there are also several options for getting started on your own terms:

• Launch a managed cluster on Spice Cloud
• Try Spice 2.0 open source
• Say hi in the Spice Community Slack
• Explore Spice.ai Enterprise
• Get a demo from a Spice engineer

Additional 2.0 Highlights

• Tool Registry. Replaces per-tool schemas with searchable tool_search and tool_invoke meta-tools, roughly 10x fewer tool-definition tokens per turn for large tool sets.
• User-Defined Functions. Declarative SQL and remote HTTP UDFs, auto-registered as LLM tools and propagated across executors.
• DataFusion v54. Sort pushdown makes top-K queries on pre-sorted data roughly 30x faster, a rewritten sort-merge join drops TPC-H Q21 from minutes to milliseconds, and dynamic filters prune files and rows mid-execution.
• Data connectors (40+). Elasticsearch, Azure Cosmos DB, GCS, ADBC, DuckLake, Git, and catalog connectors for PostgreSQL, MySQL, MSSQL, and Snowflake. The HTTP connector turns REST APIs into federated tables, with OAuth2, pagination, and predicate-driven parameters.
• DML/DDL: INSERT/UPDATE/DELETE write-back for PostgreSQL, Snowflake, DynamoDB, and Arrow
• Data operations. MERGE INTO and PARTITION BY on Cayenne, DML write-back for PostgreSQL and Snowflake, and read/write Iceberg.
• Search and AI. Hybrid search (vector, BM25, and relational) extended to Elasticsearch, multi-vector embeddings, DuckDB HNSW indexes, MCP streamable HTTP transport, provider-aware prompt caching, and the Responses API across all providers.

See the release notes for the full list.