Querying a Million-Device Topology Map with ServiceRadar Atlas

ServiceRadar Atlas evaluates set expressions such as (VLAN 20 OR VLAN 30) AND unavailable EXCEPT maintenance against an inventory of 1.1 million devices in approximately one millisecond and projects the result onto the topology map without recomputing its layout. This post describes the Roaring bitmap index behind it, reports measurements on a synthetic fleet, and compares the approach with existing open-source and commercial tools.

atlas topology roaring-bitmaps rust elixir arrow webgpu performance

ServiceRadar Atlas is the topology component of ServiceRadar. It maintains a single layout of every device in an installation's inventory, computed on the server and delivered to the browser as map tiles. This post describes a query facility built on that map. An operator supplies a set expression over inventory attributes, and Atlas evaluates it against the full inventory and returns, for each visible map element, whether it satisfies the expression or how many of its constituent devices do. Positions are not recomputed. Evaluation is performed on the server using Roaring bitmaps and completes in approximately one millisecond for an inventory of 1.1 million devices.

(VLAN 20 OR VLAN 30) AND unavailable EXCEPT tag maintenance=true

The expression above combines two VLAN memberships, an availability state and a tag using union, intersection and difference. We are not aware of an open-source network monitoring or source-of-truth tool that evaluates expressions of this form against a live topology map. The commercial platforms that offer comparable filtering produce a new map of the matching subset rather than annotating an existing one. The sections that follow describe the index structure that makes evaluation inexpensive, the projection of results onto map tiles, measurements taken on a synthetic fleet, and a comparison with existing tools.

How it works

Persistent identifiers

Each canonical device is assigned a 32-bit identifier that is retained across merges, deletion and restoration, layout rebuilds and restarts. Bitmaps address devices by this identifier rather than by position in any layout or result.

One bitmap per value

Vendor, region, VLAN assignment, device class, operating system, configured tags and availability are each indexed as one Roaring bitmap per distinct value. A device is a member of exactly the sets whose values it carries.

Queries as set operations

AND, OR and EXCEPT compile to Roaring intersections, unions and differences. Facet counts are cardinalities of the result against each value, computed on one consistent snapshot of the index.

Authorization as a set

The requesting user's effective visibility is a bitmap that is intersected into every result, count and tile projection. Negation is evaluated relative to that authorized universe.

Projection onto tiles

The result is intersected with the membership of each visible glyph. Aggregates report exact match counts, and the browser receives one flag and one count per glyph it already holds; member lists are not transmitted.

Layout independence

A query changes only visibility and counts. Positions come from a layout computed once for the whole inventory, so the map does not reflow while a filter is edited.

Why it is fast

Every canonical device in Atlas is assigned a 32-bit integer identifier when it enters the inventory. The identifier is persistent: it is retained across record merges, deletion and restoration, layout rebuilds and process restarts, and it is independent of the device's position in any layout. The query index consists of one Roaring bitmap per distinct value of each indexed field (vendor, region, VLAN assignment, device class, operating system, each configured tag key and availability state), together with one bitmap for the set of devices currently in the inventory. A Roaring bitmap is a compressed integer set that partitions the 32-bit space into blocks of 65,536 values and stores each block as a sorted array, an uncompressed bitmap or a run-length list, whichever is smallest for that block's population. Set operations are performed block by block, so the cost of an intersection, union or difference is proportional to the number of populated blocks the operands share rather than to the number of members. The expression above compiles to three such operations.

VLAN 20 OR VLAN 30

AND unavailable

EXCEPT maintenance

result: 5 devices

Figure 1. Evaluation of the example expression over 24 device identifiers. Each row is one bitmap; the final row is the bitwise combination of the three above it. The production index applies the same operations to bitmaps covering the entire inventory.

Facet counts are derived from the same result. For each value displayed in the filter interface, Atlas intersects the result bitmap with that value's bitmap and reads the cardinality of the intersection. Roaring maintains per-block cardinalities, so fifty such counts against one result complete in a few milliseconds. Authorization uses the same mechanism: the requesting user's effective visibility is itself a bitmap, and it is intersected into every result, count and tile projection before a response is constructed. Negation is therefore evaluated relative to the authorized universe, and no expression can reveal the existence of a device outside it.

Terms are not restricted to exact values. A term may specify a prefix of a tag name or value, an IPv4 or IPv6 network that is matched against every address associated with a device (a device with several addresses in the network is counted once), or one of the named prefix tags that ServiceRadar already applies to flow records, which Atlas treats as a device group. Each of these is resolved to a bitmap before evaluation, so a query for the unavailable devices within a set of branch-office address ranges is expressed and evaluated in the same way as the VLAN example.

On the map

The layout is computed once for the entire inventory and partitioned into tiles. Each tile contains a bounded number of glyphs, where a glyph represents either a single device or an aggregate of devices too dense to draw individually at that zoom level. While a query is active, Atlas intersects the result bitmap with the membership of each glyph the browser currently holds. A device glyph receives a match flag; an aggregate glyph receives the exact number of its members present in the result. Zooming into an aggregate requests the next page of its members with the same expression applied. At no point is the browser sent the membership of an aggregate or any inventory-wide set. It receives one flag and one count per glyph, in the order of the geometry it already holds.

The structure from which tiles are built is held in a graph store. Atlas records adjacency, containment and attachment evidence in Dgraph, so the questions a layout depends on, which devices are connected and which groups contain which members, are answered by graph traversal. The layout is derived from that graph once, and the bitmap index answers membership questions independently of it.

All data delivered to the browser is binary. Tile geometry is encoded as Apache Arrow IPC and decoded once into typed arrays that are uploaded to a WebGPU renderer. Membership, health and traffic state are delivered as compact typed frames whose rows correspond positionally to the geometry already held. No JSON is parsed on this path and no per-node or per-edge JavaScript objects are allocated, which keeps interaction latency stable as the inventory grows.

The index is maintained incrementally. A change to a device's availability, VLAN assignment or tags is reflected in subsequent query results within seconds, and only the affected flags and counts change on the map. The layout is unaffected.

Numbers

Measurements were taken on a synthetic inventory of 100,000 infrastructure devices and 1,000,000 endpoints with declared distributions of vendor, region, VLAN, device class and tags. The inventory was evaluated twice: once with compact identifiers and once with sparse identifiers containing the gaps left by simulated merges and deletions. Figures are 95th-percentile latencies for the native index after warm-up, with no result caching.

Operation	Compact identities	Sparse identities
Four-term AND and EXCEPT query	0.23 ms	1.16 ms
Query plus 50 exact facet counts	2.48 ms	3.44 ms
Index memory after sustained churn	64.0 MB	90.2 MB
Membership update for 64 visible tiles	under 60 KB, decoded in about a millisecond

Table 1. Native index measurements on the synthetic 1.1 million device inventory.

How this compares

The prevailing approach to a question such as which devices on VLAN 20 or 30 are unavailable is to filter a tabular view and then render a map of the filtered subset. The commercial network modelling platforms implement this well. Forward Networks exposes its model of collected configuration and state through a query language, NQE, in which a single query can select every interface in a given access VLAN across the estate. IP Fabric's technology tables accept filters composed of nested AND and OR groups that can be saved per table. NetBrain constructs maps on demand from device groups defined by criteria and overlays data views on them. In each case the map is an output of the query: a new rendering of the subset, laid out for that question.

Open-source tools provide less. The NetBox topology views plugin renders documented cabling and filters by name, site, tag and device role; VLAN is not among its criteria, and the result depicts the intended network rather than the observed one. Monitoring systems such as LibreNMS and Zabbix render maps of polled devices organised by group. We did not find an open-source tool that evaluates a boolean expression over live attributes against a map whose layout is preserved, at any scale.

Tool	How a filter is expressed	What the map shows	License
ServiceRadar Atlas	AND, OR and EXCEPT over inventory attributes, VLAN assignment, tags, prefix tags and CIDR, evaluated on Roaring bitmaps	The same fixed layout with matches highlighted in place and exact counts in collapsed clusters, over live inventory and availability	Open source
Forward Networks	NQE queries over a normalized model of collected configuration and state	A map of the selected devices and paths	Commercial
IP Fabric	Nested AND and OR filter groups on technology tables, saved per table	A map drawn from the selected subset of a snapshot	Commercial
NetBrain	Device groups defined by criteria, with data views layered on the map	A dynamic map built on demand for the group	Commercial
NetBox topology views	Name, site, tag and device role	The documented cabling for the filtered devices	Open source

Table 2. Filtering and map behaviour of comparable tools, based on public documentation as of October 2026.

The distinction is where evaluation occurs and how its cost scales. In a relational source of truth, each filter is a SQL query over many-to-many membership tables whose rows are serialised through an ORM, after which a browser-side layout library must place the returned nodes. The layout step is the binding constraint: force-directed layout is not interactive beyond a few thousand nodes, so the map must be a small subset and the filter is what selects it. The commercial platforms hold the network in stores of their own, NetBrain in a document database and Forward Networks in a precomputed path index, and still produce a new rendering per query. Atlas separates the two concerns. Structure is held in a graph store and laid out once for the full inventory; membership is held in an in-memory bitmap index whose evaluation cost depends on the number of populated blocks and not on the number of matching devices. The result is projected onto glyphs the browser already holds, so an inventory of a million devices can be queried with a four-term expression in approximately one millisecond without any change to its layout.