This page is the honest orientation: what OrdinateDB is, what state it is in, how it thinks, and the five ideas you need before anything else in these docs makes sense. If you have run a plant historian before, budget ten minutes.
What OrdinateDB is
OrdinateDB is an open-source time-series data platform. In industrial use it takes the role of the process historian. The time-series archive, the asset model, the calculation engine, episodes (batch, downtime, shifts), visualisation and the public API ship together as one system — not as a suite of separately licensed modules. It installs with one docker compose up and is licensed Apache-2.0, all of it. There is no open-core boundary: no feature held back for a paid edition, no capacity tier, no enterprise unlock. Ordinate Systems Ltd stewards the project and earns its keep through Managed OrdinateDB, support and services; the platform itself is free and complete.
Who it is for
Three audiences, roughly in order of how often they arrive here: sites running a plant historian today and wondering what else exists; engineers evaluating at a renewal or new-project moment, when switching costs are briefly finite; and integrators who build and maintain historians for other people and want a system whose whole surface is scriptable.
A statement of maturity, since you will work it out anyway: OrdinateDB is Pre-release. The specifications — the design documents the system is built from — are published in full. This documentation is mostly stubs, and every stub is marked as one; the pages that exist (this one, and the PI engineer’s guide) are written and current. If a page claims to be documentation, it is. If it isn’t yet, it says so.
The design posture
Four commitments run through every subsystem. They are the reason the system exists in this form rather than another.
Raw-first. Nothing in the write path performs lossy compression, silently or otherwise. What the collector acknowledged is what the archive holds. Data is only ever thinned through a lifecycle policy that a named person wrote and approved — and any query that touches a thinned range says so in the result, not in a footnote.
Honest by construction. Gaps render as gaps. Every aggregate carries its quality fraction (pct_good), the count of lossy ranges it crossed, and whether any of its inputs were entered by a human. Provenance travels with every number, through the API and onto every screen; there is no configuration that turns it off.
Model-driven. A template defines an asset class once — its series, limits, calculations, displays and entry forms — and the fleet inherits it. The fourteenth crusher costs the same engineering effort as the second. Where an individual asset departs from its template, that drift is tracked, not hidden.
No lock-in. The cold tier is documented Parquet, readable by DuckDB, Spark or pandas with no OrdinateDB process running. The entire surface is a versioned public API, and the portals are clients of it — nothing the UI can do exists outside the contract. Leaving should be a decision, never a project.
The five-minute mental model
Five statements. Everything else in these docs is elaboration.
- The model is the namespace. Assets live in a hierarchy; there is no flat tag list underneath it. You address data through the plant, not through a naming convention.
- Attributes own series. A series belongs to
crusher_2.motor_power, not to a tag name someone chose in 2009. Re-instrument the motor and history stays where it belongs — on the asset. - Everything is versioned. Model changes, templates, calculations, displays: all queryable as-of any moment. Ask what the model looked like last March and you get an answer, not an archaeology project.
- Provenance travels. A number never arrives without its quality fraction and its origin.
- Episodes name spans of time on assets. Batches, downtime, shifts, campaigns — one concept, one query surface.
A worked example ties these together. Read the average motor power on crusher cr-102, line 2 of the Kazakhstan mining site, over the last hour:
$ ordctl query 'avg(motor_power_kw)' \
--asset mining_kz/line-2/cr-102 --window 1h
value 741.86 kW
window 2026-07-14T12:00Z/PT1H
pct_good 96.4%
lossy_ranges 2
manual_origin 1 valueThe path is the model — site, line, asset — and motor_power_kw is an attribute of the asset, not a tag. The value arrives with its confession: 3.6% of the window was not good data; two ranges inside it have been thinned under an approved lifecycle policy; one contributing value was entered by a person. You learn all of this in the same response as the number, which is the point.
What it deliberately doesn’t do
The non-goals are stated as plainly as the goals, because knowing what a historian will never do is part of trusting it:
- No silent lossy compression, anywhere in the write path.
- No invented values — it does not interpolate across an outage and present the result as data.
- No telemetry. The historian does not phone home.
- No proprietary formats — nothing you store is readable only through OrdinateDB.
- No tag-count licensing, or per-point metering of any kind.
- No SSO tax — OIDC single sign-on is in the free core, not an enterprise tier.
The full list lives on the open-source page, and it is locked in the project’s governance rather than in marketing copy: removing an item is a governance change, not an edit.
Where to go next
If you know the PI System, read the PI engineer’s guide — it maps concepts one by one and is candid about the deliberate differences. If you would rather poke at a running instance, the live demo runs the synthetic multi-site mining model used throughout these docs. And if you want the claims with their working shown, the spec library is published in full — every substantive statement on this site cites a section of it.