New: prepared statements, UPDATE and DELETE, and key lookups that seek — 0.143 ms through the gateway.Read the update

Use case · Public Sector

Public Sector

Government platforms host many departments on shared infrastructure, each with statutory limits on who may see what. In most databases that limit is a filter the optimizer may move. In UltraFabric it is a proof the data node checks.

Workload shape

WritesRecords and case files
ReadsLookups, reports, cross-department analytics
TenancyStatutory boundaries
DeploymentOn-prem, air-gapped
Where the design fits

How the data lands

Design fit, not a customer claim: which parts of UltraFabric carry which parts of this workload.

  • Departments as tenants, with the boundary enforced as a key range rather than a predicate
  • Self-hosted on the department's own hardware; no call to any cloud at runtime
  • Every verifier decision audit-logged with the plan's fingerprint
In SQL

What it looks like

A department's analysts see their department's cases; a plan that could read another department's rows is refused with SQLSTATE 42501.

CREATE TABLE case_files (id bigint PRIMARY KEY, office text NOT NULL,
  opened date, status text, subject text);

SELECT office, status, count(*)
  FROM case_files GROUP BY office, status ORDER BY office, status;
Status

Built today, coming next

Everything in the first column is in the repository and tested; the second column is the roadmap in order.

Built today

  • Single-node self-hosted deployment with a local gateway
  • Tokens verified at the gateway and again at the node
  • Verifier decisions recorded with the request fingerprint

Next

  • Replication and the control plane
  • Row-level policies compiled on the node
  • A public declared-leakage register for timing and resource channels

Tell us about yours.

Early access starts with a conversation about the workload you would move first.