Layer 02 · Data Layer
Offline-first data that stays typed end to end
Persist, sync, and query business data offline-first. Schema definitions, relational storage, object files, and search all share the same typed interfaces — built for applications that must work without connectivity.
Why this layer
Built into the platform, not bolted on
Every module in this layer solves the same class of problem the same way — regardless of who implements it.
01
Schema is the source of truth
Define your data model once. Types flow through the SDK, database, API, and search indexes automatically — no drift between layers.
02
Works without connectivity
SQLite sync keeps clients functional offline. Conflict resolution and background sync are platform defaults, not custom infrastructure you maintain.
03
One client for every data operation
Queries, transactions, file uploads, and full-text search share the same typed client. No separate ORM, S3 SDK, and Elasticsearch adapter to wire together.
Canonical implementation
One path for every author
Junior developers, senior engineers, and AI agents produce the same standard output.
How Conflux does it
Data operations follow the registry, not your preferences
Schema changes deploy through CLI. Migrations are versioned. Sync rules, storage policies, and search indexes update from the same definition your application code imports.
Canonical path
conflux.schema.define() generates types, migrations, and API shapes
Local SQLite syncs to tenant-scoped relational storage
Object storage uses signed URLs with tenant access policies
Search indexes rebuild automatically on schema or data changes
What you get
Build field apps and web clients that work offline
Eliminate type drift between frontend, backend, and database
Ship search and file storage without third-party SDK sprawl
Migrate schemas with versioned, deployable history
01 · Data Layer
Define data once, use it everywhere
Typed schema definitions generate migrations, SDK types, and API shapes from a single source. Schema changes are versioned and deployable through CLI.
Schema · One canonical path
SDK
import type { Order } from '@conflux-stack/schema'CLI
conflux schema migrate
Config
schema: models: [Order, Customer]
What's possible with Schema
01
Typed schema definitions with migration history
02
Shared types across SDK, database, and API layers
03
Schema changes versioned and deployable through CLI
02 · Data Layer
Relational data with tenant isolation
Transactions and queries through one typed client aligned to Conflux schema. Tenant-scoped databases with isolation guarantees — not a separate ORM choice per team.
Database · One canonical path
SDK
await conflux.db.orders.create({ ... })CLI
conflux db status
Config
database: isolation: tenant
What's possible with Database
01
Relational data with ORM aligned to Conflux schema
02
Transactions and queries through one client interface
03
Tenant-scoped databases with isolation guarantees
03 · Data Layer
Offline-first sync out of the box
SQLite-backed clients stay functional without connectivity. Server-wins conflict policy, automatic background sync in the browser, and scoped pull/push are platform defaults.
Sync · One canonical path
SDK
await client.flushPendingSync() // or autoSync in browser
CLI
conflux sync status
Config
# server-wins is the platform default (sync engine)
What's possible with Sync
01
Offline-first SQLite sync for web and mobile clients
02
Conflict resolution with deterministic merge rules
03
Background sync when connectivity returns
04 · Data Layer
Files and objects with signed access
Upload, store, and deliver assets through tenant-scoped buckets with signed URLs and optional public object paths — one API for every file operation.
Storage · One canonical path
SDK
await conflux.storage.putObject(bucketId, key, bytes)
CLI
conflux storage objects put --bucket … --key … --file …
Config
storage: buckets: [uploads, assets]
What's possible with Storage
01
Object and file storage with signed upload URLs
02
Tenant-scoped buckets with access policies
03
CDN-backed delivery for public assets
05 · Data Layer
Search that stays aligned to your schema
FTS5 indexes from model.searchable fields. Queries use ?q= / client.search.query with bm25 ranking — no separate search cluster.
Search · One canonical path
SDK
await client.search.query('products', { q })CLI
# use SDK or GET /v1/.../products?q=
Config
model('products', fields, { searchable: ['name', 'sku'] })What's possible with Search
01
Full-text search across platform data models
02
Structured filters aligned to schema types
03
Search indexes maintained automatically on write
Explore
Continue through the platform
Nine layers, one cohesive stack. Browse adjacent layers or return to the full registry.