xcon-db — one operational database for connected fleets

758M

rows — a full continent of OpenStreetMap (Asia) in one table

~25 ms

nearest-point spatial query — an index lookup, not a scan

~15 GB

the whole continent as one portable package, attached read-only

Measured on a single node against a continent-scale OpenStreetMap extract. The spatial index keeps nearest-point queries index-bounded as the dataset grows — a full scan of 758M rows this is not.

The problem

Stop syncing three versions of the same device

A location update goes into the time-series store. Its latest value goes into the device database. Session and lease state goes into Redis. Then background jobs try to keep all three consistent — and every one of them is a failure mode, a backup path, and a thing to secure.

The usual fleet stack

ClickHouse   ← telemetry history
   +
MongoDB      ← device state
   +
Redis        ← TTL / sessions
   +
PostGIS      ← spatial
   +
sync jobs    ← keep them agreeing

With xcon-db

xcon-db

one write path
one query surface
one tenant boundary
one binary to run

How it works

Four data shapes, one engine

xcon-db keeps each shape a fleet needs in its native form — and puts them all behind one durable, Postgres-speaking endpoint.

Telemetry that stays sparse

Store each reading once; reconstruct dense timelines at query time. A channel declared FILL HOLD carries the last observed value across gaps, so a device shadow is one query — and a filled value never touches disk.

Current state, in rows

Keep vehicle and device metadata in row tables — the document-store shape, one live row per id, next to the telemetry it describes. No second database to register, look up, or back up.

Ephemeral state, with TTL

Sessions, leases and short-lived flags live in key/value tables that expire on their own. The cache your fleet needed is a table in the same engine — no Redis to run beside it.

Location, natively

A first-class GEO column with GEO_BBOX, GEO_DWITHIN and nearest-X ordering by geo_distance. Map windows, radius search and reverse-geocode are plain SQL — no spatial service on the side.

Durable before the ack

Writes are fsync'ed (group commit) before they are acknowledged, then compressed into columnar segments in the background. Fresh writes and compressed history are always queried together.

A tenant is a directory

One self-contained directory per customer database — back up, move or delete a tenant as one folder. Package a table to a single file and attach it read-only on any node: curated data distribution without a replication protocol.

One conversation

One request shouldn't cross three databases

Show the last known state of every vehicle in this map window, with its latest speed, and find the nearest depot. In a conventional stack that request crosses a cache, a document store and a time-series system. Here it is one database conversation — timeseries, rows and location together.

Declare intent — FILL and RETENTION per channel and table.
Filter in space and time — GEO_BBOX / GEO_DWITHIN beside the time filters.
One driver — the Postgres client you already ship.

-- one schema: stream, registry, depots
CREATE TABLE telemetry (
  speed DOUBLE FILL HOLD STALENESS 60 s,
  pos   GEO
) WITH (RETENTION 90 d);
CREATE ROWS TABLE depots (name TEXT, pos GEO);

-- last state of every vehicle in the map window
SELECT entity, speed FROM telemetry
  WHERE GEO_BBOX(pos, 40.8, 28.5, 41.3, 29.5)
  LATEST ON ts PARTITION BY entity;

-- nearest depot to a point
SELECT name, geo_distance FROM depots
  WHERE GEO_DWITHIN(pos, 41.0151, 28.9795, 5000)
  ORDER BY GEO_DISTANCE LIMIT 1;

Install

One binary. No cluster, no companion services.

Install from the apt repository; the service starts in setup mode and waits. A short web wizard collects the data directory, the listen ports and the admin — then the node is running.

# add the repository, then install
curl -fsSL https://apt.xcon-db.com/KEY.asc | sudo gpg --dearmor -o /usr/share/keyrings/xcon-db.gpg
echo "deb [signed-by=/usr/share/keyrings/xcon-db.gpg] https://apt.xcon-db.com stable main" | sudo tee /etc/apt/sources.list.d/xcon-db.list
sudo apt update && sudo apt install xcon-db

Reach the setup wizard over an SSH tunnel — ssh -L 8086:127.0.0.1:8086 your-server, then open http://127.0.0.1:8086. No coordinator, no JVM tuning, no external cache to keep in sync. Full steps in the installation guide.

Put one fleet workload on one database

Install xcon-db, connect with your Postgres driver, and try telemetry, device state and spatial queries together — then decide.

Install xcon-db → Read the docs

Run the fleet, not the database stack