DESIRED STATE → RUNNING STATE
Operator
Watches the declared platform description and reconciles it into running Kubernetes objects. The description lives in a file you can review, version, and roll back.
Architecture
Five components. One governed path.
Clarté is deliberately small enough to reason about: five platform components, two control surfaces, and one query engine — all running inside infrastructure you control, next to storage you already own.
BUILT ON DUCKDB · DUCKLAKE · POSTGRESQL · KUBERNETES · S3-COMPATIBLE STORAGE
- COMPONENTS
- Operator · control plane · query surface · catalog · UI shell
- ENGINE
- DuckDB + DuckLake — one pod, scaled vertically
- STATE
- PostgreSQL catalog — replicated, backed up, restore-tested
The shape
Everything on one diagram.
No hidden services, no vendor-hosted control plane, no second data path. What is on this diagram is the platform.
The components
Five parts, each with one job.
Each component has a single responsibility and a named boundary with its neighbours — which is what makes the platform reviewable.
POLICY · CREDENTIALS · AUDIT
Control plane
Compiles access policy, brokers short-lived scoped storage credentials, aggregates audit records, and runs scheduled queries. It is the only component that can mint storage authority.
EXECUTION
Query surface
Accepts sessions over pg-wire, HTTP, and Arrow Flight, and executes governed SQL on DuckDB with DuckLake table metadata. One deliberate engine — not a fleet to babysit.
POSTGRESQL
Catalog
Holds table metadata, platform state, and audit records — the most operationally important state in the platform, and the most protected: replicated, continuously backed up, restore-tested.
FIVE SURFACES
UI shell
SQL, Catalog, Queries, Audit, and Admin in the browser — five governed surfaces over the same path the protocols use, not a parallel access model.
ALREADY IN YOUR ESTATE
- Kubernetes
- Any conformant cluster you approve — European cloud or self-hosted.
- Object storage
- Your S3-compatible buckets hold the analytical data as Parquet.
- Identity
- Your OIDC issuer authenticates every session. Claims map to roles.
Two control surfaces
Topology is declared. Application state is served.
Cluster topology and application state have different lifecycles, so Clarté refuses to blur them into one interface.
SURFACE 1 · CLUSTER TOPOLOGY
Declarative platform state
Which components run, at what size, against which storage and identity providers — declared in one reviewed description and reconciled by the operator until the cluster matches it.
Because the description is declarative, GitOps is the natural workflow: generate manifests, review them, commit them, and let the cluster converge.
SURFACE 2 · APPLICATION STATE
Policies, schedules, and audit
Access policies, scheduled queries, and audit history live behind an authenticated API with database-backed state — versioned, transactional, and queryable.
The split is deliberate: topology follows the cluster's lifecycle, application state follows the database's lifecycle, and neither pretends to be the other.
ONE ENGINEOne query runs on one node, scaled vertically. That is a measured decision, not a limitation to hide — and if your workload genuinely needs a distributed engine,the evaluation will say so.
Failure is a design input
What breaks, how it is noticed, what happens next.
A platform earns trust by stating its failure behaviour up front. These are the responses the architecture is built around.
FailureNoticed byResponse
Query pod restartsLiveness probesThe pod restarts and clients reconnect. Committed data and metadata are unaffected.
Catalog primary failsManaged failoverA synchronous replica is promoted. A committed transaction is never traded for write speed.
Control-plane leader failsLease releaseA standby replica takes over without touching the query path.
Policy engine unavailableHealth checks and alertsNew governed sessions are refused. The platform fails closed, never open.
Catalog state corruptedWeekly restore drillPoint-in-time recovery, rehearsed on a schedule — practiced before it is needed, not improvised after.
Adoption path
Runs beside what you have. No big-bang cutover.
Clarté is designed to be adopted table by table, next to an incumbent engine — and to make retiring that engine a decision, not a leap.
01 / Query in place
DuckLake reads existing Iceberg tables where they sit. Point Clarté at the metadata and run the first governed queries without moving a byte.
02 / Move tables one at a time
Copy hot tables across, validate row counts and checksums, and swap BI connections table by table.
03 / Retire the old engine
When the last query moves, the incumbent platform is retired. Until then the two run side by side — indefinitely if that is what the estate needs.
MIGRATION PRESSURE IS NOT A FEATURE · THE TWO PLATFORMS CAN RUN SIDE BY SIDE INDEFINITELY
Next step
Walk this architecture against a real workload.
Bring your query shapes, roles, and deployment constraints. The evaluation checks every boundary on this page against what you actually run.