NGSI-LD FIWARE Context Brokers vs Unified Namespace: Which Fits Your Twin?

Two communities have spent a decade solving what looks like the same problem, and they have barely read each other’s documentation. Smart-city and data-space engineers built NGSI-LD FIWARE stacks: a JSON-LD graph of entities held by a context broker and queried over a REST API. Factory engineers built the Unified Namespace: a hierarchical MQTT topic tree where every system publishes its current state. Both claim to be “the single source of truth for your digital twin,” and both are right about a different kind of truth.

This matters in 2026 because the two worlds are colliding. Manufacturers are asked to join data spaces that speak linked data, while city operators want factory-grade telemetry at the edge. Picking the wrong backbone means a rewrite when the first cross-organisation requirement arrives.

You will leave with a precise mental model of each approach, a worked NGSI-LD entity, subscription and temporal query, an honest failure-mode list, and a decision matrix.

What this covers: the NGSI-LD information model and ETSI CIM standard, the FIWARE broker landscape, the Unified Namespace and Sparkplug model, a side-by-side analysis, failure modes, and a bridging pattern.

Context and Background

NGSI-LD is the Next Generation Service Interface for Linked Data, specified by the ETSI Industry Specification Group on Context Information Management (ETSI CIM). The API specification is ETSI GS CIM 009. The most recent published version I could verify on ETSI’s site is V1.9.1, dated July 2025; earlier editions such as V1.6.1, V1.7.1 and V1.8.1 are the ones many brokers still target. The same group publishes the information-model and cross-domain ontology work that the API builds on.

The lineage matters. FIWARE began as a European Future Internet programme and produced NGSIv2, a simpler JSON API that the original Orion broker implements. NGSI-LD replaced the ad hoc JSON with JSON-LD, so that every attribute name resolves to a globally unique IRI (Internationalized Resource Identifier). That single design move is what lets two organisations exchange data without a shared database schema: the meaning travels with the name.

FIWARE is not one product. It is a catalogue of Generic Enablers, with the context broker at its core. The broker implementations that speak NGSI-LD include Orion-LD (a C-based fork of the original Orion, backed by MongoDB), Scorpio (developed by NEC, built on Quarkus with Kafka for pub-sub), and Stellio (developed by EGM, licensed Apache 2.0). Mintaka is a companion service that serves the temporal API from a TimescaleDB store. The FIWARE Smart Data Models initiative then supplies the shared vocabulary: its GitHub organisation lists 105 repositories and 13 subject domains such as Smart Cities, Agrifood, Energy, Water, Manufacturing and Robotics, described as open licensed.

The Unified Namespace (UNS) comes from a different tradition. It grew out of ISA-95 thinking, MQTT and the Sparkplug specification, which the Eclipse Foundation announced as ISO/IEC 20237:2023. The UNS idea is architectural rather than a standard: one broker, one topic hierarchy such as enterprise/site/area/line/cell, and every producer publishes its latest state there. We covered that pattern in depth in our unified namespace architecture guide, and the protocol-level contest in OPC UA FX vs MQTT Sparkplug B.

The thesis of this post is simple and, I think, absent from most comparisons. A UNS is organised by where data lives (a path), while NGSI-LD is organised by what data is (a typed entity with relationships). Paths are excellent for routing and subscribing to live state. Typed graphs are excellent for meaning, joins and cross-boundary exchange. Your twin needs one, the other, or both depending on whether its hardest problem is velocity or semantics.

For authoritative detail, read the ETSI NGSI-LD specification front page and the Orion-LD repository.

The NGSI-LD Reference Architecture

In short: an NGSI-LD system stores entities, each with typed properties and relationships, in a context broker. Clients create and query entities over HTTP, subscribe to changes, and read history through a temporal API. A shared JSON-LD @context gives every term a global meaning, and context source registrations let brokers federate.

Figure 1: Reference architecture of an NGSI-LD FIWARE deployment. Devices reach the broker through an adapter, the broker keeps current state separately from history, and a shared @context sits behind everything.

The diagram shows the moving parts. Devices speak whatever protocol they speak; an IoT Agent or a custom adapter converts measurements into NGSI-LD entities. The broker holds current state. A temporal store appends history. Subscriptions push changes to consumers. The registry of context sources lets this broker answer queries by forwarding to others. The dashed lines show the part newcomers underestimate: the shared @context and the data models it points to are infrastructure, not documentation.

The information model: entities, properties, relationships

The NGSI-LD meta-model has three first-class building blocks. An Entity has a URI identifier and a type. A Property carries a value, and may itself carry metadata such as an observation timestamp or a unit. A Relationship points to another entity by URI. Because a Relationship is distinct from a Property, a broker can traverse a graph without guessing which strings are references.

The specification also defines GeoProperty (a GeoJSON value), and in recent editions LanguageProperty, VocabProperty, ListProperty and JsonProperty, each with normalized and concise representations. Properties and relationships can themselves have properties, which is how you express “this temperature was observed at 10:02 by sensor X with unit CEL” without inventing a side table.

Contrast this with an MQTT topic. A topic string like acme/pune/line3/press7/temperature encodes four facts in its path and one in its payload. Nothing in the protocol says that press7 is a machine, that it belongs to line3, or that the payload unit is Celsius. Those are conventions your team must document and enforce. In NGSI-LD the equivalent is a typed entity with an explicit isPartOf relationship and a unitCode on the property, queryable by type.

JSON-LD and the @context: where meaning lives

JSON-LD turns short attribute names into IRIs by way of a @context. A client can write temperature; the broker expands it to something like https://smartdatamodels.org/dataModel.Environment/temperature using the context document. Two parties who resolve the same context agree on meaning without agreeing on spelling.

The API gives you two ways to supply that context. With Content-Type: application/ld+json, the @context is embedded in the payload body. With plain application/json, you pass it in a Link header whose relation is http://www.w3.org/ns/json-ld#context. The specification also defines a core context (the ETSI-hosted ngsi-ld-core-context.jsonld) that is always applied, and clauses for storing, listing and serving user contexts from the broker itself.

This is elegant and also the first operational risk. If a context URL is unreachable when the broker needs to expand a term, requests fail. I return to this under failure modes.

The API surface

The REST binding exposes entity CRUD under /ngsi-ld/v1/entities, batch operations (create, upsert, update, delete, merge), a query language with filters on attribute values, geoqueries using georel, geometry and coordinates, pagination, attribute projection, scopes, and entity ordering. Subscriptions live under /ngsi-ld/v1/subscriptions and notify over HTTP or, through a defined MQTT notification binding, over MQTT. Context source registrations live under /ngsi-ld/v1/csourceRegistrations. Multi-tenancy is addressed by the NGSILD-Tenant header.

Distributed, federated and centralised

The architecture clause of the specification distinguishes centralised, distributed and federated deployments. In a distributed setup, a broker holds registrations describing which other context sources hold which entity types or attributes, and it forwards matching queries. This is the feature that makes NGSI-LD a data-space technology rather than only a database API: the city holds traffic data, a utility holds energy data, and a client queries one endpoint that fans out.

Fan-out has costs. The federating broker is only as fast as its slowest source, partial failure semantics must be handled by the client, and access control must be enforced per source. Orion-LD documents support for distributed operations through registrations, and notes in the same README that it is near-compliant with v1.6.1 with selected newer features. In other words, check the conformance of your chosen broker per feature rather than trusting “NGSI-LD compliant” as a binary.

Deeper Analysis: A Worked NGSI-LD Example

The fastest way to understand the model is to run it. The following examples use Orion-LD’s default port 1026. The same payloads are valid against any conformant broker, subject to its feature coverage.

Creating an entity

curl -X POST 'http://localhost:1026/ngsi-ld/v1/entities' \
  -H 'Content-Type: application/ld+json' \
  -d '{
    "@context": [
      "https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld",
      "https://example.org/contexts/plant.jsonld"
    ],
    "id": "urn:ngsi-ld:Press:pune-line3-press7",
    "type": "Press",
    "temperature": {
      "type": "Property",
      "value": 71.4,
      "unitCode": "CEL",
      "observedAt": "2026-10-13T02:50:00Z"
    },
    "state": { "type": "Property", "value": "RUNNING" },
    "location": {
      "type": "GeoProperty",
      "value": { "type": "Point", "coordinates": [73.8567, 18.5204] }
    },
    "isPartOf": {
      "type": "Relationship",
      "object": "urn:ngsi-ld:Line:pune-line3"
    }
  }'

Everything the earlier MQTT topic left implicit is explicit here. The entity has a URN, a type, a unit expressed with a UN/CEFACT-style code, an observation time, a geometry and a typed link to its line. The context https://example.org/contexts/plant.jsonld is a placeholder I invented for illustration; in production you would host your own or reuse a Smart Data Model context.

Querying by type, value and relationship

curl -G 'http://localhost:1026/ngsi-ld/v1/entities' \
  -H 'Link: <https://example.org/contexts/plant.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
  --data-urlencode 'type=Press' \
  --data-urlencode 'q=temperature>70;isPartOf=="urn:ngsi-ld:Line:pune-line3"' \
  --data-urlencode 'attrs=temperature,state' \
  --data-urlencode 'options=concise'

A single request selects every press on line 3 hotter than 70 degrees and returns only two attributes in the concise form. In a UNS the equivalent is a wildcard subscription to acme/pune/line3/+/temperature followed by client-side filtering, and it only works for presses that happen to publish under that path. The NGSI-LD query is a pull on a typed model. The UNS subscription is a push on a path. Neither is better; they answer different questions.

Subscribing to change

curl -X POST 'http://localhost:1026/ngsi-ld/v1/subscriptions' \
  -H 'Content-Type: application/ld+json' \
  -d '{
    "@context": "https://example.org/contexts/plant.jsonld",
    "type": "Subscription",
    "entities": [{ "type": "Press" }],
    "watchedAttributes": ["temperature"],
    "q": "temperature>85",
    "notification": {
      "attributes": ["temperature", "state"],
      "format": "normalized",
      "endpoint": { "uri": "http://alert-service:8080/notify", "accept": "application/json" }
    }
  }'

This subscription fires only when a press’s temperature changes and the new value exceeds 85. The broker evaluates the condition, so the consumer never sees the other 99.9 percent of traffic. In a UNS, the equivalent filtering is a stream-processing rule between the broker and the consumer.

Reading history through the temporal API

NGSI-LD defines temporal representations and a temporal query language. The tutorial architecture documented by FIWARE uses Orion-LD with the ORIONLD_TROE=TRUE flag, which writes a temporal representation of entities to TimescaleDB, plus Mintaka on port 8080 to serve queries. Current state stays in MongoDB. A representative request from the tutorial pattern looks like this:

curl -G 'http://localhost:8080/temporal/entities/urn:ngsi-ld:Press:pune-line3-press7' \
  -H 'NGSILD-Tenant: plant' \
  -H 'Link: <https://example.org/contexts/plant.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
  --data-urlencode 'lastN=5' \
  --data-urlencode 'pick=id,type,temperature' \
  --data-urlencode 'format=temporalValues'

The lastN parameter, pick projection and temporalValues simplified format all appear in the FIWARE tutorial. Collection queries additionally require timerel and timeAt, and timeproperty=modifiedAt switches the time index away from the default observedAt. Pagination uses a 206 Partial Content response with Next-Page and NGSILD-Results-Count headers when count=true is set.

Figure 3: Sequence of an NGSI-LD write, a notification, and a temporal read. The broker expands terms against the @context on the way in, and Mintaka reads history that the broker appended to TimescaleDB.

Two details deserve emphasis. First, the history is a by-product of writes: every update that the broker accepts becomes a temporal record, so write amplification is a real capacity factor. Second, the current-state store and the temporal store can diverge in failure scenarios, for example if the temporal database is down while the broker keeps accepting writes. Check your broker’s documented behaviour for that case before trusting history for audit.

A note on the numbers

Orion-LD’s README mentions a Kafka consumer subsystem for time-series ingestion at roughly 1,000 to 10,000 messages per second. Treat that as the vendor’s order-of-magnitude description, not a benchmark; throughput depends on payload size, attribute count, hardware and database tuning. I am not aware of a neutral, published head-to-head benchmark of NGSI-LD brokers against an MQTT broker, and any such comparison would be apples to oranges since the unit of work differs: a broker write validates, expands and persists a typed entity, while an MQTT publish routes bytes.

The Unified Namespace Counterpart

In short: a Unified Namespace is one MQTT broker, or a cluster, holding a hierarchical topic tree in which every system publishes its latest state. Sparkplug adds a defined topic structure, birth and death certificates and a protobuf payload so that consumers can discover metrics and detect stale data.

Figure 2: A UNS data path. Edge nodes publish Sparkplug data into a site broker, which feeds an enterprise namespace consumed by historians, dashboards and twins.

The Sparkplug topic namespace is spBv1.0/{group_id}/{message_type}/{edge_node_id}[/{device_id}]. Message types include NBIRTH and DBIRTH (an edge node or device announcing its full metric set), NDATA and DDATA (changes), NDEATH and DDEATH (disconnect), and NCMD and DCMD (commands). The HiveMQ summary of the 3.0 release also describes birth certificates being stored as retained messages under a $sparkplug/certificates/ prefix for Sparkplug-aware servers. I have not re-verified the payload encoding clause directly from the specification text in this run, so consult the Eclipse Sparkplug specification for the protobuf details.

A plain UNS without Sparkplug is even looser. Teams commonly publish JSON to ISA-95-flavoured paths and document the payload shape in a wiki. That is the version where the contrast with NGSI-LD is sharpest, because the schema is purely a team convention.

What the UNS does very well

The UNS is event-driven and decoupled. A producer publishes without knowing who listens. A new consumer subscribes to a wildcard and immediately sees live state, with retained messages giving it the last known value. Latency is low, the protocol is small enough for constrained devices, and the mental model fits the plant floor: the tree mirrors the physical hierarchy that operators already use.

Birth and death certificates give Sparkplug something NGSI-LD lacks by default: an explicit liveness model. A consumer knows whether a value is “last known” or “device offline” because the edge node’s will message and death certificate say so. In NGSI-LD you would model liveness yourself, typically with an observedAt freshness check or a status property.

Where the UNS strains

Three limits show up as the system grows. First, the hierarchy is a tree, and real plants are graphs. A press belongs to a line, but also to a maintenance group, a cost centre, a product-routing network and a safety zone. A tree forces you to pick one parent and encode the others elsewhere. Second, the semantic layer is conventional, not machine-enforced: nothing prevents temp, temperature and Temperature_C coexisting. Third, history is not native; MQTT brokers deliver messages, and durable history requires a downstream historian or time-series database.

None of these are fatal. Many successful UNS deployments add a model layer on top: an asset model, a schema registry, or a contextualisation service. The honest observation is that mature UNS projects tend to rebuild a fragment of what NGSI-LD gives out of the box, and mature NGSI-LD projects tend to need a fast ingest path that looks like a UNS.

Head-to-Head: Where Each Model Wins

The two approaches differ along six axes. The table below summarises them, and the sections that follow justify the judgements. These are structural properties, not benchmark results.

Axis	NGSI-LD context broker	Unified Namespace (MQTT, Sparkplug)
Organising principle	Typed entities and relationships	Hierarchical topic path
Semantics	JSON-LD @context, IRIs, Smart Data Models	Convention, ISA-95 naming, Sparkplug metrics
Interaction style	Request/response plus subscriptions	Publish/subscribe with retained state
History	Temporal API defined in the standard	Not in protocol, add a historian
Cross-organisation exchange	Designed for it, federation via registrations	Possible, but needs bridging and agreed schemas
Typical strength	Meaning, joins, interoperability	Velocity, simplicity, shop-floor fit

Semantics and interoperability

The strongest argument for NGSI-LD FIWARE stacks is that interoperability is a property of the data, not of the integration project. If city A and city B both describe a parking site with the Smart Data Model for parking and resolve the same context, an application written against A works against B. FIWARE’s Smart Data Models repository spans domains from Smart Cities to Manufacturing and Robotics, which is a head start for any domain they cover.

The UNS achieves interoperability inside one organisation through governance: a naming standard, an owner, a review process. This works because the organisation controls both ends. It does not travel. When a supplier needs your line status, you either give them broker credentials and a wiki page, or you build an API. That API, in practice, ends up looking like a context broker facade.

Data spaces and regulatory direction

European data-space initiatives such as those around IDSA (International Data Spaces Association) and Gaia-X emphasise sovereignty, policy-controlled sharing and machine-readable semantics. FIWARE positions its data-space connector around NGSI-LD, using the broker as the data service behind access control. I could not verify the details of the current FIWARE Data Space Connector release in this run, so check the FIWARE documentation before committing to a specific component list.

The relevant point is architectural. Data spaces share data between organisations that do not trust each other’s infrastructure. That favours a request/response API with per-request authorisation and a self-describing payload over a shared broker everyone publishes into. For a manufacturing data space, such as the automotive pattern discussed in our Catena-X reference architecture post, the exchange layer is closer in spirit to a context broker plus connector than to a UNS.

Velocity, ordering and state

For a high-rate machine signal, the UNS has the advantage. A Sparkplug edge node can batch dozens of metrics into one protobuf message, and an MQTT broker fans it out cheaply. An NGSI-LD update of a single attribute carries JSON-LD overhead and passes through context expansion and a database write. The standard does provide batch operations and the MQTT notification binding, and Orion-LD’s Kafka subsystem exists for time-series ingestion, but the design centre is entities, not streams.

A worked illustration, with illustrative numbers rather than measurements: suppose 2,000 machines each emit 20 metrics once per second. That is 40,000 metric updates per second. Published as 2,000 Sparkplug messages per second (one per machine), a broker handles it comfortably. Written as 40,000 single-attribute NGSI-LD updates per second, you would be well outside the order-of-magnitude figure Orion-LD’s README gives for its Kafka path, unless you batch. The correct pattern is not to push raw samples into the broker at all. Aggregate at the edge, and send the NGSI-LD broker state changes and one-minute summaries.

Graph queries and the digital twin

A digital twin is more than a stream of readings. It is a model of things and how they connect, queryable for questions like “which lines depend on the compressor that just tripped”. NGSI-LD’s relationships make that a first-class operation, and the specification’s query language supports filters over linked entities in recent editions. A UNS cannot answer it without an external model.

This is where the twin conversation connects to information models. If you are also weighing Asset Administration Shell, DTDL and OPC UA information models, note that they are model languages, whereas NGSI-LD is a model plus API plus exchange semantics. A pragmatic arrangement is to author asset types in AAS or OPC UA, project them into NGSI-LD entities for exchange, and keep the raw signals on the UNS.

Figure 4: Decision flow. Cross-organisation exchange or a graph-heavy model points to NGSI-LD, high-rate machine telemetry points to a UNS, and either choice usually ends in a bridge to the other.

The broker landscape in practice

Choosing a broker is a separate decision from choosing the model. Orion-LD is the most widely documented in the FIWARE tutorials and uses MongoDB for current state; its licence is AGPL-3.0, which matters if you embed or modify it in a proprietary product. Its README is candid that it is near-compliant with v1.6.1 and supports selected newer features, and that the latest Docker tag should not be used in favour of a pinned release. As of that README the latest release was 1.12.0 from January 2026.

Stellio carries an Apache 2.0 licence, which is simpler for commercial embedding. Scorpio is a microservice design with Kafka between its services, which brings scalability but also more components to operate. Whichever you pick, test the exact features you rely on: temporal operations, scopes, entity maps, distributed operations and the v1.8 and v1.9 additions are the typical gaps. A conformance matrix built from your own test suite is more valuable than any vendor statement.

Trade-offs, Gotchas, and What Goes Wrong

Every architecture has a way to fail quietly. These are the ones I would test for first.

The @context becomes a single point of failure. Term expansion needs the context document. If the URL is hosted on a server you do not control, and it moves, goes down or silently changes, your writes and queries fail or, worse, resolve differently. Host contexts yourself, version them with immutable URLs, pin them in clients, and verify that your broker caches them and what it does on a cache miss. The specification includes clauses for a broker to store and serve contexts, which is the safer route for production.

Context drift across organisations. Two parties reference plant.jsonld but one has edited it. IRIs now differ and queries return nothing, with no error. Treat contexts as versioned artefacts with a release process, exactly as you would a database schema.

Write amplification and history cost. Because temporal records follow writes, a chatty device multiplies storage. Use observation timestamps carefully, filter unchanged values at the edge, and plan retention and compression for the temporal store. The FIWARE documentation links a dedicated page on enabling temporal data compression for Stellio, which signals that this is a recognised concern.

Federation tail latency and partial failure. A federated query is bounded by the slowest source. Decide up front whether the client wants partial results, and whether a missing source is an error. Authorisation must also be enforced at each hop, so a broker that forwards a query should not become a confused deputy that exposes data the caller could not reach directly.

Conformance gaps. “NGSI-LD compliant” hides version and feature differences. A client written to v1.9 features may fail against a v1.6.1-oriented broker.

UNS-specific failure modes. Topic sprawl, conflicting payload shapes, and retained-message staleness are the usual ones. A retained value from a machine that was decommissioned months ago looks identical to a fresh one unless you encode freshness. Sparkplug’s death certificates help; a hand-rolled JSON UNS has no equivalent.

Treating either as a database. A context broker is not a general analytics store, and an MQTT broker is not a historian. Both fail when asked to be one.

Bridging the Two Worlds

The sensible production answer for many programmes is both, with a clear boundary. The UNS carries operational telemetry within a site. A small adapter subscribes to selected topics, aggregates, maps each machine to an NGSI-LD entity type, and upserts state changes into a context broker. External partners, city systems and data-space connectors talk to the broker.

The mapping is the real work. Decide the entity identity scheme (a stable URN per physical asset, not per topic), the property naming source (Smart Data Models where they exist, your own context where they do not), and the relationships that the topic tree cannot express. Keep the adapter stateless, idempotent and replayable, so a broker outage means a replay rather than a data gap.

In the other direction, the broker’s MQTT notification binding or an HTTP-to-MQTT bridge can publish context changes into the UNS, so that plant consumers see enriched events such as “press 7 entered maintenance by work order WO-123” without learning a second protocol.

Practical Recommendations

If your twin is internal to one plant or one company, and its hardest problem is moving high-rate machine state to many consumers, start with a UNS. Add an asset model and a schema discipline early. Do not adopt a context broker on day one just because linked data sounds principled.

If your twin must exchange data with other organisations, spans heterogeneous domains such as a city’s mobility, energy and environment systems, or must participate in a data space, start with NGSI-LD and reuse Smart Data Models before inventing your own. Treat the @context as a governed artefact from the first commit.

If both conditions hold, as with a manufacturer feeding a supply-chain data space, run both and bridge at the site edge. Checklist:

Pick the broker by tested feature coverage and licence, pinning exact release tags.
Host and version your own @context documents, and test broker behaviour when they are unavailable.
Aggregate or filter at the edge before writing to a context broker.
Assign stable entity URNs per physical asset, independent of topic paths.
Define retention and compression for the temporal store before go-live.
Decide federation failure semantics and per-source authorisation explicitly.
For a UNS, encode freshness and ownership, and adopt Sparkplug if you need birth and death semantics.
Keep raw high-rate signals off the context broker.

Frequently Asked Questions

What is NGSI-LD and who maintains it?

NGSI-LD is an API and information model for exchanging context information as linked data. It is maintained by the ETSI Industry Specification Group on Context Information Management and published as ETSI GS CIM 009. The most recent version I verified is V1.9.1 from July 2025. It uses JSON-LD so that entity attributes resolve to globally unique identifiers, and it defines entities, properties, relationships, subscriptions, temporal queries and context source registrations.

What is the difference between NGSI-LD and FIWARE?

NGSI-LD is a specification. FIWARE is an open-source ecosystem of components, including context brokers that implement the specification, such as Orion-LD, Scorpio and Stellio, plus related services like Mintaka for temporal queries and the Smart Data Models for shared vocabularies. You can use NGSI-LD without FIWARE by choosing a different compliant broker, and FIWARE also supports the older NGSIv2 API.

Can a Unified Namespace replace an NGSI-LD context broker?

Only when everything stays inside one organisation and your semantics can be governed by convention. A UNS has no native typed relationships, no standard query language and no built-in history. It excels at live state distribution. If you need cross-organisation exchange, graph queries or standard temporal access, you will either add a model layer on top of the UNS or add a context broker beside it.

Which NGSI-LD broker should I choose?

Choose by tested feature coverage, not name. Orion-LD is the most documented and uses MongoDB but is AGPL-3.0 licensed. Stellio is Apache 2.0 licensed. Scorpio uses a Kafka-based microservice design. Verify support for the features you need, including temporal operations, scopes, distributed operations and the newer specification versions, and run your own load test with realistic payloads, because no neutral cross-broker benchmark that I could verify exists.

Does NGSI-LD support time-series data?

Yes, through a temporal representation and query language defined in the standard. In the FIWARE reference setup, Orion-LD writes temporal records to TimescaleDB when the TROE option is enabled, and Mintaka serves temporal queries such as lastN, with timerel and timeAt for collections. It is suited to entity history and moderate rates. For very high-frequency sensor data, a dedicated time-series pipeline is usually a better fit.

Can NGSI-LD and Sparkplug work together?

Yes, and it is often the best arrangement. Sparkplug carries high-rate telemetry on the plant network, and an adapter maps selected metrics into NGSI-LD entities for external sharing. The two solve different problems: Sparkplug defines how edge nodes announce and update metrics over MQTT, while NGSI-LD defines how typed entities are exchanged and queried across systems. Keep identity mapping and idempotent replay as explicit design points.

NGSI-LD and FIWARE Context Brokers vs Unified Namespace: Which Data Model Fits Your Twin? (2026)