Databases
Un moteur OLTP. Un moteur d’analyse.
SQLite via Osage Base (OLTP, default)
Every Osage Cloud application stores its operational data in SQLite through Osage Base. WAL mode always on; per-tenant file sharding for multi-writer scale; Litestream for durable replication. The same engine in local dev, staging, production, and air-gapped deploys.
Why: one engine, one backup story, one replication story; no vendor-locked managed-database bill; FIPS-aligned; air-gap capable; composes natively with the CEK envelope (encrypted column type is a first-class feature in Base).
ClickHouse (analytics)
OLAP queries route to a separate ClickHouse cluster on DOKS. Open source, columnar, vectorised, FIPS‑buildable. Federal‑mission defensible.
Data flow: SQLite WAL events → small forwarder service → batched INSERT into ClickHouse. Sensitive columns either don’t propagate or propagate as their AAD digest for cardinality without leakage.
Vector & search
- SQLite FTS5 — full-text search; built in; well engineered.
- sqlite-vec — vector search; drop-in replacement for the few cases we’d otherwise use pgvector.
- SpatiaLite — geospatial; drop-in for PostGIS.
Supabase compatibility (API parity, not Postgres)
For apps that already speak Supabase SDKs, Osage Cloud offers a Supabase‑compatible API surface (auth, storage, realtime, edge functions, PostgREST‑shaped query API) on top of the Osage Base substrate. Your application code keeps importing@supabase/supabase-js; the backend behind the API is SQLite-via-Base with the CEK envelope and Litestream replication. Drop‑in migration path; no rewrite required.
This is API parity, not engine equivalence. The OLTP store remains SQLite by policy; we do not run production PostgreSQL.
What we don’t run in production
- ❌ PostgreSQL — not in prod, not in staging. Migration runbook on request.
- ❌ Managed RDS / Aurora / CloudSQL / Neon.
- ❌ Elasticsearch / OpenSearch — unless a regulated counterparty mandates it in writing.
Canonical spec: osage.tech/docs/storage.