Analytics Replica

Add an analytics replica to PostgreSQL, MySQL, MongoDB, and DynamoDB in minutes. Spice keeps it current with change data capture (CDC), so you get sub-second queries with no ETL.

Get a demo

View the docs (opens in a new tab)

Diagram of agents, apps, and dashboards querying a Spice Cayenne analytics replica that high-throughput CDC replication keeps current from PostgreSQL, MySQL, DynamoDB, and MongoDB, over an object store of Vortex, Iceberg, Delta, and Parquet files

Add analytics to your operational data, without ETL

Point Spice at an operational database, and Spice keeps an analytics replica up to date. Start with one table. Then add sources and join the replicated datasets in one SQL query.

Large analytical queries
on operational data

Analytical queries and AI agents run on the replica, not on your operational database.

Explore columnar storage (opens in a new tab)

Real-time freshness,
no pipelines

Spice reads the PostgreSQL WAL, the MySQL binlog, MongoDB change streams, and DynamoDB Streams directly. You do not operate Debezium or Kafka.

Explore CDC (opens in a new tab)

Sub-second query
performance

Store the replica in the Spice Cayenne accelerator, built on the Vortex columnar format. In the Spice 2.0 benchmarks, Spice 2.0 with Cayenne ran the TPC-H SF100 suite in 88.3 seconds, the fastest configuration tested.

Explore Spice Cayenne (opens in a new tab)

Built on Spice Cayenne, a high-throughput analytical engine

Spice Cayenne stores the columnar replica of your operational data, with high-throughput CDC updating the replica with every insert, update, and delete. Cayenne writes each change as a new row and marks the newest copy with a sequence number, so a write never reads the row it replaces. A background process removes old copies, so writes and queries stay fast as changes add up.

Explore Spice Cayenne

Diagram of operational databases (PostgreSQL, MySQL, MongoDB, and DynamoDB) that send CDC or refreshes into Spice Cayenne in Spice.ai. Apache DataFusion plans queries from apps, agents, and dashboards. Cayenne keeps metadata in SQLite and data files in Vortex

Build an analytics replica in minutes

PostgreSQL CDC example

An example of replicating a PostgreSQL table into a Spice Cayenne analytics replica.

# spicepod.yamldatasets:  - from: postgres:public.orders    name: orders    params:      pg_host: ${secrets:PG_HOST}      pg_db: shop      pg_user: ${secrets:PG_USER}      pg_pass: ${secrets:PG_PASS}    acceleration:      enabled: true      engine: cayenne  # Columnar storage for analytical queries      mode: file      refresh_mode: changes  # Stream every change from the WAL      primary_key: id      on_conflict:        id: upsertsql> -- orders and revenue by hour, on the replica     SELECT date_trunc('hour', created_at) AS hour,       count(*) AS orders, sum(total) AS revenue     FROM orders     WHERE created_at > now() - INTERVAL '1 day'     GROUP BY 1 ORDER BY 1;# example output2026-10-29 14:00   412   38120.502026-10-29 15:00   398   36904.25

  1. Connect your operational database

    In spicepod.yaml, add a dataset for each table to replicate. Set refresh_mode to changes, a primary key, and an on_conflict upsert rule.

  2. Run Spice

    Start Spice locally with spice run, or deploy it as a sidecar, in your cluster, or on Spice Cloud.

  3. Query the replica

    Run analytical queries from agents, BI tools, or your own apps. They run on the replica, not on your production database.

  1. /plugin marketplace add spiceai/skills
  2. /plugin install spiceai@spiceai

Connect the analytics tools your team already uses

Your current tools connect over open protocols, with no code changes. Depending on the client, use the native Spice connector for Power BI, Arrow Flight SQL, ADBC, ODBC, JDBC, or a Spice SDK.

See all integrations

Read the Power BI guide

Diagram of Power BI, Tableau, Looker, Apache Superset, and the Spice SDKs connecting through the Spice connector, Arrow Flight SQL, ODBC, and JDBC to a Spice Cayenne analytics replica

Proven in production

Teams building real-time systems at scale run Spice to serve analytics and AI from operational data.

Darin Douglass

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

Peter Janovsky

“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

FAQs

Learn how an analytics replica keeps operational data ready to query, with no ETL. Analytical queries run on the replica.

An analytics replica is a local accelerated copy of your operational tables that Spice keeps up to date. Dashboards, notebooks, and AI agents query the replica. Heavy reads do not compete with your transactional workload.

Only the initial snapshot, and any later snapshot that you configure, reads the source tables. After that, Spice reads the native change log: the PostgreSQL WAL, the MySQL binlog, MongoDB change streams, or DynamoDB Streams. All analytical queries run on the replica.

Spice has native replication for PostgreSQL, MySQL, MongoDB, and DynamoDB. It also reads change events from Debezium and appends records from Kafka topics. See the CDC documentation for the setup of each source.

About 2 seconds from a commit on the source to a query-ready row, under load. A PostgreSQL, MySQL, or DynamoDB dataset becomes ready only when its replication lag is below 2 seconds. Change this limit with the connector parameter: pg_replication_ready_lag, mysql_replication_ready_lag, or dynamodb_replication_ready_lag. These datasets stay not ready during the snapshot and while they catch up after a restart, so they do not serve stale rows. A MongoDB dataset becomes ready when Spice has applied the initial snapshot of the collection. When it resumes from a saved resume token, it becomes ready at once.

No. Replication runs inside the Spice runtime. For PostgreSQL, MySQL, MongoDB, and DynamoDB, you do not operate ETL jobs, Debezium, or a streaming layer. Start with one table and add more tables when you need them.

Any tool that supports Arrow Flight SQL, ODBC, or JDBC. This includes Microsoft Power BI through the native Spice connector, Tableau, Looker, and Apache Superset. In code, use the SpicePy Python library or the Go, Rust, Java, and JavaScript SDKs. On Spice Cloud, JDBC and ODBC need an Enterprise plan.

Analytical queries scan a columnar copy in Spice Cayenne, not the row store of your source database. In the Spice 2.0 benchmarks, one node ran 1,046 CH-benCHmark analytical queries per hour at scale factor 1000. During that run, it ingested CDC from a PostgreSQL source at more than 266,000 transactions per minute (tpmC). Native Windows builds do not include Cayenne, and every other acceleration engine is deprecated in Spice v2.4.

Yes. The Spice runtime is open source under the Apache 2.0 license, including CDC replication and the Cayenne accelerator. Self-hosting the runtime has no license fee. Spice Cloud is the fully managed option, and Spice.ai Enterprise adds self-hosted deployment with SSO, RBAC, and audit logs. Compare the plans on the pricing page.

Add a dataset to your spicepod.yaml file and set refresh_mode: changes. Spice copies the table once, then streams each committed insert, update, and delete into a local accelerated copy. Analytical queries run on that copy, not on your production database.

"Operational databases" "Analytics clients and agents" WAL binlog change streams DynamoDB Streams Arrow Flight SQL, ODBC, JDBC Arrow Flight SQL, ODBC, JDBC Arrow Flight SQL, ODBC, JDBC "Spice analytics replica with Cayenne acceleration" PostgreSQL MySQL MongoDB DynamoDB "Power BI and Tableau" "Python, SDKs, and notebooks" "AI agents"
  1. Connect: point a dataset at a table in your operational database.
  2. Replicate: set refresh_mode: changes, a primary key, and an on_conflict upsert rule for that key. Spice takes a snapshot, then reads the native change log.
  3. Query: run SQL against the replica from the Spice portal, a BI tool, an SDK, or an AI agent.

The following Spicepod replicates a PostgreSQL orders table into a Spice Cayenne accelerator:

version: v1
kind: Spicepod
name: orders-analytics

datasets:
  - from: postgres:public.orders
    name: orders
    params:
      pg_host: ${secrets:PG_HOST}
      pg_db: shop
      pg_user: ${secrets:PG_USER}
      pg_pass: ${secrets:PG_PASS}
      pg_sslmode: verify-full
    acceleration:
      enabled: true
      engine: cayenne
      mode: file
      refresh_mode: changes
      primary_key: id
      on_conflict:
        id: upsert

When the dataset is ready, query it with standard SQL. The query runs on the replica:

SELECT date_trunc('hour', created_at) AS hour, count(*) AS orders, sum(total) AS revenue
FROM orders
WHERE created_at > now() - INTERVAL '1 day'
GROUP BY 1
ORDER BY 1;

Each source uses its own change log. Spice creates the replication objects it needs, but the source must allow replication. The table lists the main requirements. Each linked doc has the full list of settings and privileges:

SourceChange logMain source requirementsDocs
PostgreSQLWrite-ahead log (pgoutput)wal_level = logical, free replication slots, and a role with REPLICATION and SELECT on the tablesPostgreSQL replication
MySQLBinary logBinary logging on, binlog_format = ROW, binlog_row_image = FULL, an empty binlog_row_value_options, and replication and SELECT privilegesMySQL replication
MongoDBChange streamsA replica set or sharded cluster, a user with the changeStream privilege, and primary_key: _id on the datasetMongoDB change streams
DynamoDBDynamoDB StreamsStreams on with the NEW_AND_OLD_IMAGES view type, and IAM permissions to read the streamDynamoDB Streams

Each dataset also needs a primary key and an on_conflict upsert rule for that key. For PostgreSQL, Spice creates a publication and a replication slot for each dataset. Datasets that name the same pg_replication_slot share one slot and one replication connection. Spice also reads Debezium change events, over Kafka or pushed to Spice directly, and it appends records from Kafka topics.

With a file-backed accelerator (mode: file), Spice saves its position in the change log. By default, it resumes from that position on restart and does not copy the table again. To take a new snapshot on each start, set pg_replication_initial_snapshot, mysql_replication_initial_snapshot, or dynamodb_replication_initial_snapshot to always. With an in-memory accelerator, Spice takes a new snapshot on each start by default. If the source no longer holds the saved position, Spice stops with an error by default. A new copy starts only if you allow it: set mysql_replication_invalid_checkpoint_behavior or dynamodb_replication_invalid_checkpoint_behavior to restart, or mongodb_resume_token_invalid_behavior to rebootstrap.

ApproachFreshnessQuery engineExtra systems to operate
Database read replicaUnder a second to secondsSame row store as productionOne more database server
ETL or ELT into a warehouseMinutes to hoursColumnar warehousePipelines, a scheduler, a warehouse
Spice analytics replicaAbout 2 secondsColumnar accelerator (Spice Cayenne)None: replication is in the runtime

A read replica copies the full database into the same row store, so large scans stay slow. Spice copies only the tables you list into the columnar Spice Cayenne accelerator. It can join them with other sources in one query.

For freshness controls and recovery paths, read analytics replicas for operational data. To join the replica with other sources, see SQL Federation and Acceleration. For dashboard migration steps and workload examples, see real-time analytics on operational data.

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)