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

Use case · Smart Cities

Smart Cities

A city platform collects from traffic, lighting, water, waste and safety systems, each owned by a different department, often with different vendors. The platform must share infrastructure without sharing data by accident.

Workload shape

WritesContinuous sensor streams
ReadsDashboards, incident lookups, reports
TenancyDepartments and vendors
SensitivityCitizen data under clearance
Where the design fits

How the data lands

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

  • One tenant per department, or per vendor contract, on a single cluster
  • Counters and sensor events as columnar collections; incidents and assets as rows
  • Fields above a user's clearance masked by the verifier, not by application code
In SQL

What it looks like

A department's token scopes every table it touches; no WHERE clause carries the boundary.

CREATE TABLE junction_counts (id bigint PRIMARY KEY, junction text NOT NULL,
  minute timestamp, vehicles int, avg_speed numeric(6,2)) WITH (storage = columnar);

SELECT junction, avg(avg_speed), sum(vehicles)
  FROM junction_counts GROUP BY junction ORDER BY 3 DESC LIMIT 20;
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

  • Clearance-based field masking enforced in the verifier
  • Append-only columnar collections with duplicate keys rejected at insert
  • Identity derived only from the token the node verified

Next

  • Row-level policies compiled on the node
  • Vector and text search behind the same verifier
  • The managed service after replication and backups

Tell us about yours.

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