Introduction
Andromeda is an open-source NGSI-LD context broker written in Rust. It stores entities such as sensors, vehicles or buildings, together with their properties and the relationships between them, keeps their history in PostgreSQL with no separate history service, and notifies subscribers when they change. It implements NGSI-LD v1.9.1 (ETSI GS CIM 009), the ETSI standard for context information, and is released under the EUPL 1.2.
Andromeda is a strict NGSI-LD broker that refuses invalid requests. Many systems read from the same broker, so a mistake the broker accepts reaches all of them. Andromeda checks every request against the semantics of NGSI-LD, not only its syntax. A request can be well-formed JSON and still say something the specification doesn't allow. Andromeda refuses it, with an error that names the member and the rule it breaks.
It works with what you have
NGSI-LD exists so that systems from different vendors can exchange context data without custom glue. The API, the data model and the JSON-LD vocabulary mechanism are all fixed by the standard. A producer, a dashboard or another broker that speaks NGSI-LD already knows how to talk to Andromeda, because it talks to every other compliant broker the same way.
Andromeda implements NGSI-LD v1.9.1 in full: every endpoint, every operation and the behaviour the specification describes for each. A compliant client needs no Andromeda-specific code, library or plugin.
A client that follows the specification gets the answers the specification describes. A client written against a more lenient broker may rely on requests the specification doesn't allow, and Andromeda refuses those with a 400. Common refusals lists the usual ones.
What you can build with it
Andromeda keeps the current state of your things, remembers how it got there, and tells other systems when it changes. You write data in once and read it back in the shape each consumer needs.
- Keep a live picture of your things. Build the digital twin of a fleet, a building or a city. Store sensors, vehicles, buildings or anything else as entities with properties and links between them, and change them one at a time or thousands at once.
- Ask questions instead of fetching everything. The query language selects entities by type, by what their values say (
temperature>30), or by following a link from a bus to its route to its operator. - Search by place. Geoqueries find everything near a point, inside an area or crossing a line, and return the answer as GeoJSON your map already understands.
- Look back in time. Every attribute keeps its history, so you can chart last week, fetch the last ten readings or ask for hourly averages without a separate time-series database.
- Push changes instead of polling. Subscribe to the entities you care about and receive a notification over HTTP or MQTT the moment they change.
- Join several systems into one. Register other brokers as context sources and a single query reaches all of them, or answer their queries from your own data.
- Serve several customers or projects. Each tenant gets its own isolated data on the same broker.
What makes it different
- Written in Rust. Andromeda is one native program with no virtual machine and no garbage collector, so it starts quickly, uses memory predictably and never pauses while a runtime cleans up. The language rules out memory corruption and data races. Rust clients can use the
ngsi-ldcrate, which every guide uses in its Rust examples. The JSON-LD, IRI and RDF libraries underneath the broker are published crates as well. - Your data stays correct. Andromeda never guesses what a request meant or quietly drops part of it. Numbers are stored exactly, up to 131,072 digits before the decimal point and 16,383 after, and timestamps keep microsecond precision. Each change and its history are written in the same transaction, so the history never falls behind. Where the specification leaves a choice open, Andromeda picks one answer, gives it on every endpoint and documents it in the behaviour pages.
- It keeps working when something fails. During a database outage, requests get a
503withRetry-After, a client can safely repeat any write, and background work picks up where it stopped once the database is back. A context source that keeps failing can be held back for a cooldown instead of slowing every query. - Notifications get through. In durable mode a notification is queued in the same transaction as the write that caused it, and a failed delivery is retried with a growing delay. A slow endpoint holds up no other subscription.
- It looks after its own database. Built-in maintenance vacuums and analyses tables and rebuilds bloated indexes while the database is quiet, and logs every decision it makes. With online repacking turned on, it also rewrites bloated tables while they stay readable and writable, and gives the freed space back to the disk.
- Simple to run. A deployment needs one PostgreSQL server with PostGIS and TimescaleDB. There is no message queue, cache or separate history service to run beside it.
- Built to be right. Every compiler and lint warning is an error, a failure is reported to the caller instead of crashing the broker, and automated checks enforce the boundaries between layers. More than 17,000 tests cover it, including the ETSI NGSI-LD conformance tests and the examples from annex C of the specification. The design pages explain how.
- Built to be fast. Requests are decoded straight into typed values, and the database schema and its indexes are shaped around the way NGSI-LD reads and writes. Andromeda publishes no speed figures until it has a benchmark suite anyone can rerun, and the benchmarks page explains how to judge it on your own workload in the meantime.
- Nothing hidden behind the standard. Anything beyond the specification is an extension, off by default apart from cursor pagination, which a client gets only by asking for a cursor. With the extensions off, Andromeda behaves like any other compliant broker, so you can move between brokers without relying on something only one of them offers.
Where Andromeda fits
NGSI-LD is the common API of the FIWARE ecosystem and of the data spaces built on it. Producers such as IoT agents write entities, and applications and dashboards query them or subscribe to their changes. Andromeda runs in each of the architectures the specification describes.
- Centralised. In a single-broker deployment, one broker holds the data and answers every request.
- Distributed. In a distributed deployment, context sources register what they hold, and Andromeda forwards the matching part of each request and merges the answers. In a data space it can take the other side, as a source that keeps its data and shares it on its own terms.
- Federated. In a federated deployment, the context sources are themselves brokers, run by other teams or organisations, so one query reaches all of them.
The standards page lists the standards Andromeda relies on.
Where it stands
Andromeda is stable and extensively tested, but nobody runs it in production yet, so it has no track record the way established brokers do. Project status says what the 1.0 release covers and what you can rely on when you upgrade.