Telemetry on columnar collections today; a time-series engine next.
Plant telemetry, metrics and view counts land in append-only columnar collections now. A dedicated engine with series identity, rollups and retention is a named roadmap step with a named benchmark. It is not built.
Planned, not built Planned
| Phase | P3t, after the SQL phases (P3d, P3e) |
|---|---|
| Benchmark | TSBS (Time Series Benchmark Suite) |
| Compared with | TimescaleDB, QuestDB |
| Gate | ingest at or above TimescaleDB; range and rollup queries at or below 1× their time, on the dedicated benchmark host |
Planned, not built. Nothing on this page exists as running code. The specification and the roadmap say what it will be and how it will be measured; no number will be published for it until it is measured on a dedicated benchmark host against the named systems.
What the specification already says
These items are written down in the architecture specification and the plan language, reviewed, and will be built as written or revised in the open.
Series identity and typed points
Each point carries a unit and a quality flag, and the engine records event time separately from ingest time.
PlannedLate data and watermarks
Points that arrive after their event time are accepted under a watermark rule rather than dropped or silently re-ordered.
PlannedRaw data and rollups
Rollups are stored with the method and the completeness that produced them, so a dashboard can say what it is showing.
PlannedRetention and downsampling
Per-series retention with downsampling into rollups; the garbage-collection horizon the storage engine already has is the base for it.
PlannedA specification first
The roadmap requires a new section of the specification, reviewed by the owner, before the phase starts. That section is not written yet.
PlannedOperators behind the same verifier
The plan language that every SQL statement compiles to already lists these operators. When the engine arrives, it arrives behind the check that tenant isolation and access filters are applied on every data access.
| Operator | What it is specified to do |
|---|---|
SCAN with partition pruning | The plan language already carries partition_key fields per collection, and the distributed rewrite prunes partitions from tenant and partition atoms. |
GROUP and WINDOW | Decomposable aggregates (count, sum, min, max, avg, variance, quantile sketches) and a WINDOW operator with partition, order and frames are specified in the plan language. |
One security model. The roadmap's rule is that every read, whatever the engine, compiles to the plan language and passes the verifier. No side door for a new engine.
What carries this workload now
Built parts that serve the need until the engine exists, and the parts that do not exist yet.
Columnar collections
Append-only, created with WITH (storage = columnar). Timestamps, integers and decimals are stored frame-of-reference and bit-packed; each row group header carries min/max per column.
BuiltDurable ingest
Every write is in the write-ahead log before it is acknowledged; with 32 concurrent clients on the development host, 17 writes shared each fdatasync on average.
BuiltTenant isolation
A tenant's telemetry lives in that tenant's key range; row groups sit inside it, so no raw request can reach another tenant's series.
BuiltZone-map skipping
The header min/max exists, but scans do not skip row groups by predicate yet.
PlannedStraight answers
Can I store time series in UltraFabric today?
Yes, in a columnar collection: an append-only table with the same SQL, schema and tenant isolation as a row table. There is no series type, rollup or retention policy yet; those are the planned engine.
When is the time-series engine measured?
At the end of its phase, on TSBS against TimescaleDB and QuestDB on a dedicated benchmark host. Until then no time-series number is published.
Follow the gate, not the promise.
The status page lists each phase, its gate and the measurement behind it, and the updates page records each step as it lands.