Postgres that thins its own history and tells you what happens next.

A managed Postgres database with horizon tables: time-series tables bounded in both directions. Old rows downsample themselves as they age. Future rows are forecast ahead by competing methods, scored against what actually arrives, over typed entities the database itself validates, connected into a graph you can draw.

Horizon tables

One statement, in both directions of time

A horizon table covers unbounded history in finite space, and writes its own future ahead of now.

• History thins itself. Raw this week, then five-minute, hourly and daily as chunks age. Years of data stay cheap to query; this week stays exact.
• Methods compete. Every enrolled method writes its own forecast rows, and reality scores each one as it lands.
• The champion is earned. Rank 1 on the leaderboard comes from measured error, never from a benchmark claim.
• The console draws it. Each table gets a chart of its competing futures, and an entity linked to its slice shows its own forecast on its own page.

-- turn an ordinary table into a horizon table
SELECT chrono.create_horizon_table('readings', 'ts',
  '1 day', '1 day', '1 hour', 'linear', true);

-- enrol competitors; every method writes its own future
SELECT chrono.add_forecast_method('readings', 'seasonal_naive');
SELECT chrono.add_forecast_method('readings', 'seasonal_linear');

-- reality scores them as it arrives; rank 1 is EARNED
SELECT method, mape_pct, rank
  FROM chrono.method_leaderboard('readings');

Continuous aggregates you configure and maintain are a different shape of answer. Here retention, downsampling and forecasting are properties of the table, and the error rate is a column you can query rather than a claim in a benchmark. The console charts each table’s competing futures, and an entity linked to its slice of a table shows its own forecast on its own page.

Typed entities

Validation the database enforces, not your app code

Everything you track is an entity with a type, and the type decides what the database accepts.

• Open types learn. Unknown names auto-register, and declared units fill themselves in when a writer omits them.
• Strict types refuse. Undeclared metrics, wrong units and out-of-range values are rejected at insert, whichever client wrote them.
• Enforcement lives in the database, not in app code that some client forgot to run.

SELECT postfinite.declare_metric('turbine', 'rpm', 'rpm',
  'float8', 0, 4000, NULL);

INSERT INTO chrono.entity_telemetry (ts, entity_id, metric_name, metric_value)
VALUES (now(), 'turbine-a1', 'wattage', 900);
ERROR:  Metric "wattage" is not declared for this device's type
        (strict enforcement). Declare it with postfinite.declare_metric().

Types also carry a full taxonomy: categories, domains, and a relationship vocabulary, surfaced in the console and queryable like everything else.

The graph

Entities connect with verbs

this pump feeds that tank is a row.

• Open types teach the registry. Connect two entities with a new verb and the vocabulary learns it.
• Strict types demand declaration first, verb and cardinality both. The same posture as telemetry.
• Traversal ships with the table, bounded on depth and size.
• The console draws the whole graph with click-through, platform entities included.

INSERT INTO chrono.entity_edges (source_id, target_id, relationship)
VALUES ('pump-01', 'tank-3', 'feeds');

SELECT * FROM chrono.neighbors('tank-3', 'both', NULL);
SELECT * FROM chrono.subgraph('pump-01', 2, 100);

Platform entities

Your database knows where it lives

Every database ships with a small set of platform-published entities: the service, the provider, the region.

• Read-only and kept current. The hourly sync converges them; the database itself refuses local edits.
• Ordinary rows in your database. Join your telemetry against the platform’s heartbeat in one query, with no API in the way.
• Relatable. Edge your entities to the infrastructure that hosts them and it shows up in your graph.

SELECT entity_id, name FROM chrono.entities
 WHERE origin = 'global';
--  pf:platform   Postfinite Cloud   (heartbeats hourly)
--  pf:neon       Neon
--  pf:us-east-1  AWS us-east-1

Also included

Plans

Every account is set up by hand, so the free tier is by request rather than instant. The paid tiers are priced but not yet purchasable, because checkout is not switched on. If one of them is the size you need, say so in your request; you will not be charged in the meantime.

Plan details could not be loaded just now. Every tier is by request; the paid ones are not yet purchasable.

What you actually get today

Managed PostgreSQL 18, provisioned for you as an isolated database. The Postfinite engine (chrono horizon tables, postfinite_auth, postfinite_nats) is applied to it as schema. Self-hosting the engine as native extensions, on the PostgreSQL 18.4 fork, is the other way to run it.

There is no documentation site yet, and nothing here is charging money. Accounts are opened by invitation: ask for one and a person reads it, and you sign in with a passkey. If you would rather talk first, the address below reaches the same person.