Self-Hosted OGC Sensor Observation Services: FROST Server vs 52°North SOS vs istSOS

Introduction

When deploying a sensor network — whether for environmental monitoring, smart agriculture, industrial IoT, or urban infrastructure — you need a standardized way to collect, store, and share observation data. The Open Geospatial Consortium (OGC) has defined two key standards for this purpose: the Sensor Observation Service (SOS) and the newer SensorThings API. Both enable interoperable sensor data exchange, but they target different use cases and technology stacks.

This article compares three open-source implementations that let you self-host sensor observation services: FROST Server (a modern SensorThings API implementation), 52°North SOS (a mature SOS standard implementation), and istSOS (a lightweight sensor data management system).

FROST Server: Modern SensorThings API

FROST Server, developed by Fraunhofer IOSB, is the reference implementation of the OGC SensorThings API. Unlike the older SOS standard that uses SOAP/XML, SensorThings API is a modern RESTful/JSON-based protocol with built-in MQTT support for real-time data streaming.

FROST Server can be deployed via Docker Compose:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

version: "3.8"
services:
  frost:
    image: fraunhoferiosb/frost-server:latest
    ports:
      - "8080:8080"
    environment:
      - persistence_db_driver=org.postgresql.Driver
      - persistence_db_url=jdbc:postgresql://db:5432/sensorthings
      - persistence_db_username=sensorthings
      - persistence_db_password=changeme
      - persistence_autoUpdateDatabase=true
      - mqtt_enabled=true
    depends_on:
      - db

  db:
    image: postgis/postgis:16-3.4
    environment:
      - POSTGRES_DB=sensorthings
      - POSTGRES_USER=sensorthings
      - POSTGRES_PASSWORD=changeme
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

Once running, you can query sensor data through standard REST endpoints:

1
2
3
4
5
6
7
8

# List all things (sensors/devices)
curl http://localhost:8080/FROST-Server/v1.1/Things

# Query latest observations from a specific sensor
curl "http://localhost:8080/FROST-Server/v1.1/Datastreams(1)/Observations?\$top=10&\$orderby=phenomenonTime%20desc"

# Subscribe to real-time updates via MQTT
mosquitto_sub -h localhost -t "v1.1/Datastreams(1)/Observations"

FROST Server’s OData-based query syntax supports sophisticated filtering, ordering, and expansion of related entities — making it ideal for building interactive dashboards and analytics tools.

52°North SOS: Battle-Tested SOS Standard

52°North SOS is the most mature and feature-complete open-source implementation of the OGC Sensor Observation Service standard. It has been deployed at research institutions, government agencies, and environmental monitoring networks worldwide for over a decade.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

version: "3.8"
services:
  sos:
    image: 52north/sos:latest
    ports:
      - "8080:8080"
    environment:
      - SOS_DATASOURCE_DRIVER_CLASS=org.postgresql.Driver
      - SOS_DATASOURCE_URL=jdbc:postgresql://db:5432/sos
      - SOS_DATASOURCE_USERNAME=sos
      - SOS_DATASOURCE_PASSWORD=changeme
      - SOS_SERVICE_URL=http://localhost:8080/52n-sos-webapp
    depends_on:
      - db

  db:
    image: postgis/postgis:16-3.4
    environment:
      - POSTGRES_DB=sos
      - POSTGRES_USER=sos
      - POSTGRES_PASSWORD=changeme
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

52°North SOS includes a comprehensive administration web interface where you can manage sensors, configure observation offerings, and test queries. It supports both the classic SOAP-based SOS 2.0 protocol and a RESTful binding extension.

Inserting an observation via the REST API:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

curl -X POST http://localhost:8080/52n-sos-webapp/api/v1/observations \
  -H "Content-Type: application/json" \
  -d '{
    "procedure": "weather_station_01",
    "observedProperty": "air_temperature",
    "featureOfInterest": "station_location",
    "phenomenonTime": "2026-06-12T10:00:00Z",
    "result": 23.5,
    "resultTime": "2026-06-12T10:00:00Z"
  }'

istSOS: Lightweight Sensor Data Management

istSOS, developed by the Institute of Earth Sciences (SUPSI) in Switzerland, takes a different approach — prioritizing simplicity and ease of deployment over comprehensive OGC compliance. It’s written in Python and designed for small to medium sensor networks.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Install via pip
pip install istsos

# Create a new istSOS instance
istsos init my-sensors

# Configure database connection in my-sensors/istsos.conf
# database = postgresql://istsos:changeme@localhost:5432/istsos
# database = sqlite:///istsos.db

# Start the server
istsos start my-sensors

istSOS provides a clean REST API for data ingestion and retrieval, plus a web-based administration interface for managing procedures and observed properties.

Choosing the Right Tool

Your choice depends on your primary requirements:

• Choose FROST Server if you want a modern RESTful + MQTT sensor platform with strong OGC SensorThings API compliance. It’s the best fit for IoT projects, smart city deployments, and any scenario requiring real-time data streaming.
• Choose 52°North SOS if you need mature SOS 2.0 compliance for interoperability with existing geospatial infrastructure, government reporting requirements, or integration with systems that speak the SOS protocol.
• Choose istSOS if you need a lightweight, easy-to-deploy solution for a small sensor network. Its Python codebase makes it accessible for customization by researchers and domain scientists.

Why Self-Host Your Sensor Observation Infrastructure?

Running your own sensor observation service gives you complete control over your environmental data. Unlike commercial IoT platforms that charge per-device fees and may change their pricing or API at any time, a self-hosted solution ensures your historical observations remain accessible and portable indefinitely.

Data sovereignty is particularly important for environmental monitoring — multi-year sensor datasets are irreplaceable, and losing access to a cloud platform’s historical data can invalidate years of research. By self-hosting with standard OGC protocols, you ensure your data can be migrated between implementations and shared with other researchers using interoperable formats.

The OGC standards also enable integration with broader geospatial ecosystems. For example, see our self-hosted IoT platform comparison for end-to-end IoT infrastructure, or our digital twin guide if you’re building simulation models that consume real-time sensor data. For edge deployments, check our IoT edge gateway comparison.

Deployment Architecture and Scaling Strategies

For small sensor networks (under 100 devices reporting hourly), a single Docker host with 2 vCPUs and 4GB RAM comfortably runs any of the three platforms alongside PostgreSQL/PostGIS. FROST Server benefits from additional resources when MQTT streaming is enabled, as each connected device maintains a persistent TCP connection.

At medium scale (100–1,000 sensors reporting every 5 minutes), consider separating the database onto dedicated hardware and enabling connection pooling. Both FROST Server and 52°North SOS rely on JDBC connection pools configured via environment variables. For PostgreSQL, set max_connections to at least 2x the number of application threads and configure shared_buffers to 25% of available RAM.

For high-throughput sensor networks (1,000+ devices with sub-minute reporting), deploy multiple FROST Server instances behind a load balancer with sticky sessions disabled — the SensorThings API is stateless. Use PostgreSQL read replicas for query-heavy workloads and consider time-series database extensions like TimescaleDB for efficient storage of high-frequency observations. The MQTT broker (Mosquitto or EMQX) should be deployed separately with its own cluster for reliability.

For environmental monitoring networks spanning multiple geographic regions, consider a federated architecture where each region runs its own FROST Server or 52°North SOS instance, and a central harvesting service aggregates observations for cross-region analysis. This pattern is used by several national environmental agencies and avoids single points of failure while keeping data close to its collection point.

Security considerations are especially important for sensor networks deployed in the field. Always deploy behind a reverse proxy with TLS termination, implement API key authentication for sensor data ingestion, and use read-only database credentials for public-facing query endpoints. Rate limiting prevents accidental or malicious flooding from misconfigured sensors. For additional IoT infrastructure guidance, see our self-hosted IoT platform comparison.

FAQ

What’s the difference between OGC SOS and SensorThings API?

SOS (Sensor Observation Service) is an older OGC standard that uses SOAP/XML for communication. SensorThings API is the modern replacement — it uses REST/JSON with MQTT for real-time updates and is much easier to integrate with web and mobile applications. Both serve the same purpose (sharing sensor data), but SensorThings API is the recommended choice for new deployments.

Can FROST Server handle millions of observations?

Yes. FROST Server uses PostgreSQL/PostGIS for storage and supports pagination, filtering, and spatial queries. With proper database indexing and sufficient hardware, production deployments handle hundreds of millions of observations. The Fraunhofer team has published performance benchmarks demonstrating linear scaling with PostgreSQL.

How do I migrate from SOS to SensorThings API?

Both FROST Server and 52°North SOS store data as relational records. You can write an ETL script that reads observations from the SOS database and inserts them into the SensorThings API using the REST endpoints. 52°North also offers a proxy extension that translates between SOS and SensorThings protocols, enabling gradual migration.

Do these tools support authentication and access control?

FROST Server supports basic authentication and can be placed behind an OAuth2 proxy like Ory Hydra. 52°North SOS includes a built-in role-based access control system. istSOS has limited built-in security and should be deployed behind a reverse proxy like Caddy with authentication middleware.

What hardware is required for a sensor observation server?

A basic sensor observation server can run on a Raspberry Pi 4 with 4GB RAM for networks of up to a few hundred sensors. For production deployments with thousands of sensors and millions of observations, a dedicated server or VM with 4+ vCPUs, 8GB+ RAM, and SSD storage is recommended. PostgreSQL/PostGIS is the primary resource consumer.

💰 想测试你的市场判断力？我用 Polymarket 做预测市场交易——这是全球最大的预测市场平台，从大选结果到技术监管时间线，什么都可以押注。和赌博不同，这是真正的信息市场：你懂的信息越多，胜率越高。我靠预测技术相关事件的走向已经赚了不少。用我的邀请链接注册：Polymarket.com