Skip to main content

The database substrate

The data platform is not a thin layer over someone else's database. Each cell carries its own local stores (a transactional store, an object store, and the engines over them) so a deployment needs no external database licence and no dependency on a vendor's control plane.

Why it matters​

A sovereign, air-gapped, or on-premises deployment cannot reach out to a cloud service to answer a query, check a policy, or record an audit event. If any of those depends on connectivity, the deployment that most needs the data platform is the one where it fails. Because the substrate is local to the cell, the platform runs the same way whether the cell is one of a hundred in a cloud region or a single box on a disconnected network.

What the substrate carries​

LayerWhat it is
Transactional storeThe platform's own embedded transactional store with a canonical schema: tables, indexes, views: discovered at runtime by convention. It is the deepest and most-exercised part of the platform.
Multi-model enginesRelational, vector, search, document, graph, time-series, and streaming tables, addressed through one governed surface rather than as separate products bolted together.
Object storeNamespaced object storage with chunked manifests, deduplication, integrity verification, and at-rest encryption: the cell's own, with adapters for external S3, Azure, and GCS storage where a deployment prefers them.
Data filesTable data is written as Parquet with column statistics and read natively, so the on-disk footprint is an open format, not a proprietary blob.

One store, many models​

The multi-model engine set means structured rows, vectors, full-text search, documents, graphs, and time series live in one governed store rather than in a fleet of separate systems a customer has to license, secure, and reconcile separately. Distributed sharding, placement, routing, rebalancing, pushdown query planning, and convergent (CRDT) replication spread that store across cells when a workload is multi-cell.

Figure C4: one substrate, many model providers. The FluxDB access layer (green) is a single uniform data access layer over two execution cores, SQLite (transactional) and DuckDB (analytical), with document, property-graph, vector, and time-series providers over the same substrate. A separate data-structure engine speaks the Redis wire (RESP2/RESP3), so a customer keeps their existing clients, but that wire re-enters the same authorizer, deny-by-default before authentication: it is not a bypass, and a structure gains classification, workspace scope, authorization, audit, and cross-cell replication that a cache does not give. This holds identically single-cell and multi-cell.

Table equivalent

ElementRoleState (meaning)
FluxDBOne uniform data access layerverified / canonical (green)
SQLiteTransactional execution core beneath the access layerneutral
DuckDBAnalytical execution core beneath the access layerneutral
Document / property-graph / vector / time-series providersModel-specific surfaces over the same substrateneutral
Data-structure engine (Redis-compatible, RESP2/RESP3 wire)Existing Redis clients, gaining scope + audit + replicationneutral
The Redis wireRe-enters the same authorizer: deny-by-default before auth, not a bypassneutral (dashed edge)

Underneath, a housekeeping layer keeps growth bounded by policy rather than by a cron script: TTL expiry, soft-delete tombstone purge, table and replication compaction, tiering across hot, warm, and cold pools, and retention windows.

Retention is tier-qualified

The retention window a deployment enforces depends on its licence tier. Retention is a governed policy of the substrate, not a fixed platform default; treat "how long is data kept" as a per-deployment configuration question.

The scope every asset carries​

The substrate does not store bare rows. Every asset carries a workspace scope, a classification, and a lineage record, and the same is true of a message as of a table. That scoping is what the next two pages build on: the boundaries those scopes enforce, and the governed read that compiles them into every query.

Across the deployment matrix​

  • Single-cell: one cell owns its stores end to end; nothing is external.
  • Multi-cell: stores shard, place, and replicate across cells, and a workspace or clean room spans them.
  • Sovereign / air-gapped: the substrate is local, so no query, policy check, or audit write reaches for a network.
  • Cloud-enabled: the same substrate, with external object stores available as an option rather than a requirement.