What is a Data Substrate? Definition, Architecture, and Use Cases | Spice AI
What is a Data Substrate?
A data substrate is the persistent, co-located data and AI layer that sits alongside your application and provides sub-millisecond access to any data source -- whether that source is a cloud warehouse, a relational database, a streaming system, or a file store. Unlike a data warehouse or lakehouse, a data substrate is not a destination where data is moved and stored permanently. It is infrastructure -- a live, queryable surface that federates, accelerates, and serves data where the application runs.
See Spice in action Read the docs
Data infrastructure evolved through several architectural paradigms: the relational data warehouse (centralized, structured), the data lake (decentralized, schema-on-read), and the lakehouse (ACID semantics over lake storage). Each paradigm answers the question: where should data be stored and how should it be organized?
A data substrate answers a different question: how should applications access data at the performance and freshness levels modern workloads require?
The substrate does not replace warehouses, lakes, or lakehouses. It federates them. It connects to every data source in the environment, serves data to applications through a unified SQL interface, and optionally accelerates hot data locally to eliminate round-trip latency. It is infrastructure that spans between application code and the data layer below.
The Substrate vs. the Destination
The distinction between a substrate and a destination is fundamental:
A data destination (warehouse, lake, database) is where data lives. Data is moved into it via ETL pipelines, DBT transformations, or streaming ingestion. It stores data at rest and answers questions about historical state at whatever freshness the ingestion pipeline provides.
A data substrate is where data is served. It does not store data permanently -- it maintains connectivity to the sources where data lives and provides applications with a queryable interface to all of them. When acceleration is configured, a local copy of a frequently accessed dataset is cached at the edge (co-located with the application) for sub-millisecond access. That cache is a projection of source data, not a canonical copy.
This distinction has practical consequences:
- No data ownership problem. Because the substrate federates rather than ingests, data governance remains at the source. Security, access control, and retention policies are enforced at the originating system.
- No stale pipeline problem. Data in a substrate is fresh by construction. Federation queries read directly from sources; acceleration caches are refreshed on a defined schedule or via change data capture. There is no ETL job that runs overnight and leaves applications querying yesterday's data.
- No proliferation problem. A data warehouse tends to accumulate copies: staging tables, marts, reporting tables, API cache tables. A substrate does not accumulate copies. It accelerates specific datasets on request and purges acceleration caches when datasets are retired.
Why "Substrate"?
The terminology is intentional. A substrate, in ecology and biology, is the underlying surface on which an organism lives -- not the organism itself. The substrate supports life; it does not direct it.
A data substrate in software architecture plays the same role. It is the foundational layer on which application logic depends for data access. Applications do not need to know whether a query is served from a local acceleration cache, a federated remote database, or a query fan-out across multiple sources. They issue SQL. The substrate handles routing, caching, and result delivery.
This abstraction is what makes a data substrate an infrastructure primitive rather than a product category. It is comparable to how a load balancer is infrastructure for HTTP traffic, or how a service mesh is infrastructure for service-to-service communication. The data substrate is infrastructure for data access.
Key Properties of a Data Substrate
1. Federation Over Multiple Sources
A data substrate connects to any data source -- cloud warehouses, relational databases, document stores, vector databases, object storage, streaming systems -- and presents them through a unified SQL interface. Applications do not need separate drivers, ORMs, or API integrations for each source. The substrate handles connection pooling, protocol translation, and query routing.
SQL federation is the mechanism that makes this possible. The substrate's query planner accepts SQL queries that reference any configured source, rewrites them into source-native queries, executes them in parallel where possible, and merges the results. Query fans out transparently; applications see a single result.
2. Co-located Data Acceleration
Latency-sensitive workloads -- realtime dashboards, recommendation systems, feature stores, AI inference pipelines -- cannot tolerate the 50-500 ms round-trip to a remote database on every query. A data substrate solves this by maintaining a local acceleration cache of frequently accessed datasets, co-located with the application (in the same pod, on the same host, or in the same data center tier).
The acceleration layer ( Spice Cayenne) stores data in a columnar format optimized for analytical queries (Vortex) and answers queries from local memory or disk with sub-millisecond latency. The cache is kept fresh via scheduled refresh or CDC-based real-time sync from the source.
This is the sidecar pattern applied to data: the acceleration cache runs as a co-located service that intercepts all data queries, serves cached data instantly, and falls back to federation for uncached queries.
3. SQL + Embeddings in a Single Interface
Modern applications do not only run SQL queries. They also perform semantic search -- finding documents, products, or records based on similarity to an embedding vector rather than exact values. A data substrate that only handles structured SQL leaves applications to manage a separate vector database with a separate query API, separate connection management, and separate result merging.
A complete data substrate serves both SQL and vector queries through the same interface. The application issues a hybrid search query -- combining keyword filters with semantic similarity -- and the substrate handles both execution paths and merges the results using reciprocal rank fusion or weighted scoring.
4. Live Connectivity Without ETL
In a traditional architecture, fresh data requires an ETL pipeline that extracts from the source, transforms to a common schema, and loads into the destination. A data substrate eliminates this pipeline for most access patterns. Direct federation reads the source in real time; CDC-backed acceleration keeps the local cache synchronized to the source as changes land.
This is what architects describe as a zero-ETL architecture -- one where applications access fresh data without the latency, cost, and fragility of ETL pipelines.
How a Data Substrate Differs From Other Architectures
| Architecture | Primary Purpose | Data Ownership | Freshness Model | Query Latency |
|---|---|---|---|---|
| Data warehouse | Analytical reporting | Centralized ingestion | Batch ETL (hours to days) | Seconds to minutes |
| Data lake | Cost-effective storage at scale | Source-adjacent files | Pipeline-dependent | Seconds to minutes via engine |
| Lakehouse | ACID transactions + open file format | Open files (Iceberg/Delta) | Streaming or batch ingestion | Seconds (engine-dependent) |
| Data mart | Business-unit-specific reporting | Derived from warehouse | Warehouse refresh cycle | Seconds |
| Data substrate | Application data serving | Federated at source | Real-time (federation) or CDC-refreshed (acceleration) | Sub-millisecond (accelerated), seconds (federated) |
The substrate is not a replacement for the warehouse or lakehouse. It is complementary. The warehouse stores historical analytical data; the substrate federates the warehouse alongside operational databases, streaming systems, and other sources, and serves the combined view to applications at latency levels the warehouse alone cannot provide.
Data Substrate as a Hybrid Data Architecture Component
The data substrate occupies the serving tier in a hybrid data architecture. In this model:
- Storage tier: Data lakes with Apache Iceberg or Delta Lake tables store historical and operational data at scale.
- Processing tier: Batch and stream processors (Spark, Flink, dbt) transform data and write results back to the storage tier or operational databases.
- Serving tier: The data substrate connects to all storage and processing outputs, federates them into a unified query surface, and accelerates frequently accessed datasets locally for low-latency access.
Applications interact exclusively with the serving tier. They do not need to know that the user profile is in PostgreSQL, the product catalog is in DynamoDB, and the purchase history is in Snowflake. The substrate knows, and it routes queries accordingly.
Implementation with Spice
Spice implements the data substrate pattern:
- Spicelets define connected data sources, their schemas, and their acceleration configuration.
- Federation queries are executed by Apache DataFusion, which rewrites SQL across all configured sources and executes them in parallel.
- Acceleration caches are managed by Spice Cayenne (Vortex-backed) for columnar datasets and DuckDB or in-memory Arrow for smaller working sets.
- CDC sync uses change data capture connectors to keep acceleration caches synchronized to source data in real time.
- Embeddings and hybrid search are handled in the same query plane -- applications can issue hybrid SQL + vector queries through the same endpoint.
Spice runs as a sidecar container alongside application code, or as a shared service for an application cluster. Either deployment model fits the co-location principle that makes the substrate pattern effective.
Advanced Topics
The Substrate as a Feature Store
Machine learning pipelines require a feature store -- a system that serves pre-computed feature values to models at inference time with low latency. Traditional feature stores are purpose-built systems with separate data ingestion pipelines, specialized storage, and custom serving APIs.
A data substrate can serve as the feature store for many ML inference workloads. Accelerated datasets contain feature values computed by upstream pipelines; the substrate serves them to the inference layer at sub-millisecond latency through SQL. Because the substrate is also the source for operational queries, feature values stay in sync with the data the application acts on -- there is no separate pipeline maintaining a parallel feature store.
Substrate-Level Query Caching vs. Application-Level Caching
Application caches (Redis, Memcached) store the results of specific API calls as opaque byte blobs. They answer exact-match lookups and cannot handle any query variation without a cache miss. They also have no awareness of data changes -- invalidation requires either short TTLs (stale data) or explicit cache keys tied to data mutation events (complex invalidation logic).
A data substrate's acceleration layer is query-aware. It stores data in structured columnar form and executes arbitrary SQL queries over the accelerated data. It handles query variations (different filters, aggregations, projections) over the cached dataset without requiring a full remote round-trip. Invalidation is data-driven -- CDC events trigger cache updates at the row level, keeping the acceleration cache fresh without TTL-based staleness.
This structural difference makes substrate-level caching more powerful than application-level caching for data workloads: it handles ad-hoc queries, stays fresh via data sync rather than TTLs, and requires no cache key management in application code.
Data Substrate at the Edge
As inference workloads move to the edge (mobile devices, embedded systems, edge servers), the data substrate pattern follows. An edge node running an AI inference model needs access to context data -- user preferences, local sensor readings, recently seen items -- without a round-trip to a central data store. A local substrate instance accelerates the relevant context data on the edge device and federates to central sources when connectivity allows.
This is a direct extension of the sidecar co-location principle: the substrate runs on the device, near the inference process, and provides the same SQL interface regardless of connectivity state.
Data Substrate FAQ
What is a data substrate?
A data substrate is a co-located data and AI infrastructure layer that provides applications with sub-millisecond access to any data source via SQL. It federates multiple sources (warehouses, databases, streaming systems) through a unified query interface and optionally accelerates hot datasets locally to eliminate round-trip latency. Unlike a data warehouse, the substrate does not store data permanently -- it serves data where the application runs.
How is a data substrate different from a data warehouse?
A data warehouse is a destination where data is ingested via ETL and stored for historical analysis. A data substrate is serving infrastructure -- it federates live data from warehouses, databases, and other sources and serves that data to applications at sub-millisecond speed. The two are complementary: the warehouse stores historical data; the substrate federates and serves it alongside operational data sources.
How is a data substrate different from a data lake or lakehouse?
A data lake or lakehouse is storage infrastructure for large-scale data organized in open formats like Apache Iceberg or Delta Lake. A data substrate is a serving layer that connects to the lake or lakehouse (and other sources) and serves data to applications at low latency. The substrate reads from the lake via federation and may accelerate the most-accessed tables locally -- but the lake remains the authoritative storage layer.
What is the relationship between a data substrate and zero-ETL?
Zero-ETL architectures eliminate the ETL pipeline between source systems and the consuming application. A data substrate is the enabling infrastructure for zero-ETL: it federates source data in real time (no extraction and loading required) and keeps acceleration caches synchronized via CDC (no transformation pipeline required). The substrate is the layer that makes zero-ETL practical for production workloads.
Does Spice implement the data substrate?
Yes. Spice is designed as a data substrate: it connects to any data source, federates queries across all sources through a unified SQL interface, accelerates hot datasets locally using Spice Cayenne (Vortex-backed columnar storage), and supports hybrid SQL + vector search in the same query plane. Spice runs as a sidecar co-located with application code, which is the canonical deployment model for a data substrate.
Learn more about the data substrate
Architecture guides on data substrate design and implementation with Spice.
[Docs\n\nSpice.ai OSS Documentation \n\nGet started with Spice as a data substrate: connect data sources, configure acceleration, and query federated data through a unified SQL interface.\n\n [Blog\n\nIntroducing the Spice.ai Data and AI Development Platform \n\nHow Spice implements the data substrate pattern to provide a unified, co-located data access layer for AI-driven applications.\n\n [Blog\n\nSpice for AI Accelerated Applications \n\nHow teams use Spice as a data substrate to serve low-latency data to AI inference pipelines without separate feature stores.\n\n