A prototype that adds geometric spatial filtering to topic-based messaging handled a higher reported message rate in a synthetic test when its spatial-filter mappings were kept in broker main memory. With 1,000 subscriptions and a spatial filter size of 2,000 peids, the main-memory mode scaled to around 250,000 messages per second before the system was no longer timely. The in-database mode performed well up to around 150,000 messages per second under the same test conditions.
A spatial layer inside MQTT
The system, called spaPS, is designed to extend topic-based publish-subscribe with expressive geometric spatial subscriptions. It combines spatial filtering and routing in the middleware, allowing the broker to handle the added spatial complexity while client implementations remain virtually unchanged. The design uses MQTT version 5 and remains conformant to the standard.
The reported performance comes from a particular prototype stack: Apache ActiveMQ Artemis served as the broker, PostGIS as the spatial database, MQTT 5 encoded the spatial filters, and Eclipse paho-mqtt provided the client implementations. The rates are therefore measurements from that implementation and its tested configuration.
The comparison centered on where the mapping lived
The central benchmark changed the location of the spatial-filter mapping. In one mode, the mapping stayed in the spatial database; in the other, it was held in the broker's main memory. The synthetic workload used 100 subscribers with 10 subscriptions each, for 1,000 subscriptions overall, and set the spatial filter size at 2,000 peids. The database-backed configuration reached its reported operating range at about 150,000 messages per second, while the main-memory configuration reached about 250,000 messages per second before timely operation ceased.
The evaluation also included a pre-processed Berlin dataset derived from OpenStreetMap. It contained a road network together with certain shops and businesses. For that workload, subscribers were generated from the distribution of road traffic, and a Zipfian distribution was used to select reference points, concentrating more selections on some points than on others. This was a generated workload, not an observation of subscribers operating in a deployed IoT system.
A benchmark with a narrow operating window
The evaluation ran on three identical machines, each using a 13th-generation processor with 24 cores. Publishers, subscribers and the spatial broker ran on separate machines. On the broker machine, the broker and the spatial database ran in separate Docker containers. This arrangement gives the comparison a defined hardware and deployment setting, while leaving uncertainty about how the same pattern would look with other hardware, networks or deployment conditions.
The system's geometric world model is quasi-static. Modeled mobile physical entities, such as vehicles or people, are outside the implemented scope, although subscribers and publishers may still be mobile. A moving client can participate in the communication pattern, but the world model does not represent the changing physical entity itself.
The results should be read as a prototype benchmark under selected conditions. The reported thresholds are approximate, and the supplied analysis reports no confidence intervals, hypothesis tests, p-values or other formal inferential analysis. The fixed machine arrangement and selected synthetic and Berlin-derived workloads leave open how the design would perform on other hardware, networks, workloads or geographic datasets.
Paper data and sources
Original title: A Spatially-Aware Publish-Subscribe Middleware for IoT Applications
Authors: Philipp Ungrund, Kurt Rothermel, Sukanya Bhowmik
Journal/Repository: arXiv
Status: Preprint, not yet peer-reviewed
First online: 2026-08-26
DOI: Not available
Original paper · Full text