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

Use case · Transportation

Transportation

Tolling, transit and fleet systems produce trip events at scale and must share them with authorities under strict terms. UltraFabric keeps each party's rows in its own key range and checks every plan against it.

Workload shape

WritesEvent streams from the road
ReadsSettlement, reporting, lookups
TenancyOperators, authorities, partners
RetentionYears, for disputes
Where the design fits

How the data lands

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

  • Trip, toll and telematics events as columnar collections
  • Vehicles, contracts and accounts as rows; retried batches are idempotent
  • Operators and authorities as tenants on one cluster
In SQL

What it looks like

An authority's token reads the authority's tenant; an operator's reads the operator's. Neither can address the other's key range.

CREATE TABLE trips (id bigint PRIMARY KEY, plaza text NOT NULL,
  at timestamp, class int, fee numeric(8,2)) WITH (storage = columnar);

SELECT plaza, class, count(*), sum(fee)
  FROM trips WHERE at >= '2026-10-22' GROUP BY plaza, class;
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

  • Row and columnar engines with answers equal to DuckDB's
  • Primary keys unique per tenant; key lookups seek to one row
  • Idempotent writes keyed by the client

Next

  • Parallel reads at a snapshot
  • Group commit for collection inserts
  • The managed service after replication

Tell us about yours.

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