---
title: "What Is an Edge Database? On-Device Storage, Sync Patterns, and Choosing the Right Stack"
description: "Edge databases run on IoT gateways and factory devices, not in the cloud. This guide covers the five main on-device options, three sync patterns, and how data reaches Tiger Cloud as the central store."
section: "Postgres for IoT"
---
> **TimescaleDB is now Tiger Data.**
An edge database is a database that runs at or near the data source rather than in a central cloud or data center. Instead of sending every sensor reading across a WAN connection, the device stores and queries data locally, then syncs to a central store when the architecture calls for it.
When choosing a database for edge devices, the footprint, write pattern, and connectivity profile drive the decision more than raw query performance.
Edge databases run on IoT gateway devices, industrial PLCs, embedded Linux systems, in-vehicle computers, smart meters, and factory floor servers. They are not running on Cloudflare edge nodes or CDN points of presence. That is a separate product category serving web developers, and this guide does not cover it.
Three reasons edge placement matters: local query response without a WAN round trip (latency), continued operation during network outages (connectivity resilience), and aggregating data before upload rather than streaming every raw reading (bandwidth cost).
"Edge database" describes a deployment pattern, not a database category. Relational, columnar, object-oriented, and time-series architectures can all serve as an edge database depending on the workload.
## Edge database vs. cloud database vs. traditional server database
| **Characteristic** | **Edge database** | **Cloud / central database** |
| --- | --- | --- |
| Location | On-device, gateway, or factory floor server | Managed data center or cloud region |
| Latency | Sub-millisecond local queries | WAN round trip required |
| Connectivity dependency | Operates offline; syncs when connected | Requires network access |
| Storage capacity | Limited by device hardware (MB to GB) | Virtually unlimited with tiering |
| Query capability | Device-scoped analytics | Fleet-wide aggregations, long history |
| Typical role | Local storage, buffering, pre-aggregation | Long-term retention, cross-site analytics, dashboards |
Cloud databases like Tiger Cloud are not edge databases. They are the central store that edge databases sync into. A traditional on-prem rack server is central infrastructure, not an edge database. Edge means co-located with the sensors or machines generating data.
Some vendors market distributed cloud products as "edge databases." For this guide, edge means at the data source, not in a regional availability zone.
## On-device edge database options: an honest comparison
Most vendor guides skip this section because they want to pitch their own product as the edge solution.. Tiger Cloud runs at the cloud tier and receives data from edge databases; it does not replace them. That framing is what makes this comparison useful.
| **Database** | **Type** | **Query language** | **Typical footprint** | **Best edge use case** | **Limitations** |
| --- | --- | --- | --- | --- | --- |
| SQLite | Embedded relational | SQL | Less than 1 MB | Offline-first transactional data; device state and configuration | Single-writer; not suited for concurrent high-throughput ingestion or time-series aggregations |
| DuckDB | Embedded OLAP / columnar | SQL | 10-20 MB | Local analytical aggregations before upload; time-series batch analysis | Not optimized for concurrent high-frequency writes; no persistent server mode by default |
| Embedded TimescaleDB (open-source extension) | Time-series extension on PostgreSQL | SQL | 100 MB+ (requires PostgreSQL runtime) | Edge gateway servers with PostgreSQL installed; time-series features at the edge node | Requires a PostgreSQL instance; not suitable for resource-constrained microcontrollers |
| Apache IoTDB | Time-series database with edge mode | IoTDB-SQL | 50-100 MB | Industrial IoT deployments wanting a single product spanning edge and cloud | Proprietary query language; less integration with standard BI tooling and the PostgreSQL ecosystem |
| ObjectBox | Embedded object-oriented | Object API | Less than 1 MB | Mobile IoT and Android/iOS edge devices; object graph storage | Not SQL; limited analytical query support; stronger for mobile than for industrial time-series workloads |
**SQLite** is the most widely deployed embedded database in the world. Its single-writer model saturates under high concurrent sensor write rates, so use it for configuration, state management, and offline queuing rather than as the primary time-series store.
**DuckDB** suits embedded analytical workloads where the goal is to compute local aggregations (1-minute averages, rollups) before upload rather than streaming raw readings. It is not designed for high-frequency concurrent writes, so it complements a write-optimized edge store rather than replacing one. Community signals from April-May 2026, including the Hacker News launches of new embedded engines (SlothDB, NeuG) explicitly positioning against DuckDB's columnar format, show the embedded analytics category is active and competitive.
**Embedded TimescaleDB** runs the open-source TimescaleDB extension on a PostgreSQL instance at an edge gateway server, giving edge nodes hypertables, continuous aggregates, and columnstore compression. This is not a microcontroller solution; it requires a capable Linux gateway, typically 1-4 GB RAM.
**Apache IoTDB** spans edge and cloud using a device-tree data model and IoTDB-SQL. Teams comfortable leaving the PostgreSQL ecosystem find it a strong fit for industrial IIoT. Teams already on PostgreSQL tooling typically choose embedded TimescaleDB instead because standard BI connectors and dbt work without adapters.
**ObjectBox** fits Android and iOS edge applications at sub-1 MB footprint. Its object-oriented API is less suited to the analytical time-series queries common in industrial IoT.
None of these replace the central time-series store. They reduce data volume traveling to the cloud, improve resilience during outages, and handle local processing. The next section covers how data moves from each of them to Tiger Cloud.
## Edge-to-cloud sync patterns
Getting data from an edge database into a central store is where most architecture guides stop short. Three common patterns cover the majority of IIoT deployments. Tiger Cloud sits at the receiving end of each; it is not an edge runtime.
### Pattern 1: MQTT-based forwarding
Sensors publish to an MQTT broker at or near the edge. A subscriber process forwards messages to the central database. The edge database may act as a local queue during connectivity gaps so no data is lost when the WAN link drops.
MQTT over TLS is the standard for IoT security. Common brokers: HiveMQ, Mosquitto, AWS IoT Core, and EMQX. See the [HiveMQ and TimescaleDB integration guide](https://www.tigerdata.com/blog/hivemq-and-timescaledb-it-just-works) for a working broker-to-Tiger Cloud pattern.
[Takton's Sense Manufacturing platform](https://www.tigerdata.com/blog/how-startup-takton-shipped-just-two-months-tiger-data) shows this architecture in production. Each Sense device runs Linux-based firmware and monitors factory equipment using amp clamps on single- or three-phase power lines and three-axis accelerometers mounted to the machine body. Telemetry transmits every few seconds over Ethernet or Wi-Fi to an AWS MQTT broker using TLS. Tiger Cloud stores the time-series data using TimescaleDB hypertables for automatic partitioning; a separate PostgreSQL instance handles device registry and configuration. Development started in July 2025 and devices ran in customer facilities by September 2025, with machine monitoring costs up to 70% lower than the closest competitors.
[WaterBridge](https://www.tigerdata.com/blog/how-waterbridge-uses-timescaledb-for-real-time-data-consistency), an oil and gas produced-water operator, uses Ignition SCADA at the edge and Chariot MQTT as the broker layer, with Tiger Cloud as the historian replacement, handling 10,000 data points per second. For a full MQTT-to-SQL pipeline implementation, see the [MQTT sensor data ingestion guide](https://www.tigerdata.com/blog/mqtt-sql-practical-guide-sensor-data-ingestion).
### Pattern 2: Logical replication / WAL-based sync
If the edge node runs PostgreSQL or embedded TimescaleDB, logical replication can stream changes to the central Tiger Cloud instance using PostgreSQL's write-ahead log. No custom sync code is required; the database handles change propagation automatically.
This pattern fits when the edge has a full PostgreSQL runtime and edge/cloud schemas are compatible. It is less common in resource-constrained IoT environments but standard in industrial gateway setups. The trade-off: logical replication requires persistent connectivity. Intermittently connected devices need MQTT queuing or batch upload instead.
For implementation depth, see [Postgres logical replication best practices](https://www.tigerdata.com/learn/best-practices-for-postgres-database-replication). For the relationship between edge nodes and SCADA historians, see [SCADA data management at scale](https://www.tigerdata.com/learn/scada-data-management-at-scale-architecture-historians-and-the-modern-database).
### Pattern 3: Batch upload / ETL
The edge database accumulates data locally and uploads in periodic batches: every minute, every hour, or triggered by connectivity restoration. Simpler than MQTT streaming but introduces latency in central visibility.
Best fit: remote field sites with intermittent connectivity (offshore platforms, satellite-connected sensors, rural installations) where near-real-time central visibility is not required. Common formats: CSV or Parquet exports to S3, direct SQL bulk inserts when connectivity is available, and AWS Greengrass batch forwarding.
## Choosing the right edge database stack
Match your constraints to the right tool. Not every IoT deployment needs an edge database at all.
**Choose SQLite alone if:**
- You need offline-first transactional storage for device configuration, queuing, or state management
- Write rates are low enough that the single-writer limit is not a constraint
- You are not running local analytical queries; all analysis goes to the cloud
- Your device has under 4 MB of available storage
**Choose DuckDB at the edge if:**
- You need local analytical aggregations before upload (computing 1-minute averages rather than streaming raw readings)
- Your workload is write-heavy in batches and read-heavy for analytics
- You have enough local storage to cache data between uploads (tens to hundreds of MB)
- You want columnar compression to reduce upload payload size
**Choose embedded TimescaleDB on an edge gateway if:**
- Your edge gateway runs Linux with 1-4 GB RAM for a PostgreSQL runtime
- You want time-series features at the edge node: hypertables, continuous aggregates, columnstore compression
- Your team already knows PostgreSQL and wants the same tooling end to end
- You need complex local queries or multi-sensor joins before forwarding data to Tiger Cloud
**Choose Apache IoTDB if:**
- You want a single time-series product spanning edge and cloud, and you are comfortable leaving the PostgreSQL ecosystem
- The device-tree data model fits your asset hierarchy
- Your team is comfortable with IoTDB-SQL and does not depend on standard PostgreSQL BI or ETL tooling
**Choose Tiger Cloud (or another managed PostgreSQL provider) as the central store (applies in all scenarios above):**
- Long-term retention with compression and fast analytical queries across all edge nodes
- Dashboards and alerting spanning multiple sites
- Edge devices that cannot hold months or years of data history
**Skip the local edge database layer entirely if:**
- Devices have reliable, low-latency network connectivity
- Write volume does not saturate the WAN link
- Local processing and offline resilience are not requirements
Adding an edge database layer adds complexity: local schema management, sync code, and failure handling. Justify that complexity with a clear requirement. If connectivity is solid and write volumes are manageable, connecting directly to Tiger Cloud is simpler and correct.
For a broader comparison at the central IoT tier, see [choosing the right IoT database for your stack](https://www.tigerdata.com/learn/how-to-choose-an-iot-database).
## Industry applications
**Manufacturing (smart factory).** Takton's Sense Manufacturing platform monitors machine vibration and power draw on factory equipment using edge devices running Linux firmware. Data flows through MQTT to Tiger Cloud. Maintenance alerts are generated centrally from multi-sensor time-series data. See the [Takton case study](https://www.tigerdata.com/blog/how-startup-takton-shipped-just-two-months-tiger-data) for the full stack. For broader IIoT context, see [IIoT and Industry 4.0 fundamentals](https://www.tigerdata.com/learn/a-beginners-guide-to-iiot-and-industry-4-0).
**Oil and gas (field telemetry).** [Flogistix by Flowco](https://www.tigerdata.com/blog/how-flogistix-by-flowco-reduced-infrastructure-management-costs-by-66-with-tiger-data) monitors gas compressor telemetry at remote field sites where connectivity is intermittent and data reliability is mission-critical. Tiger Data delivers 84% compression on stored data, 99% operational reliability, and 66% infrastructure cost reduction compared to their prior system.
WaterBridge, an oil and gas produced-water operator, uses the SCADA/MQTT pattern described above and replaced a legacy historian with Tiger Cloud. For teams deciding between historians and modern time-series databases, see [data historian vs. time-series database](https://www.tigerdata.com/learn/moving-past-legacy-systems-data-historian-vs-time-series-database). For broader industrial IoT context, see [PostgreSQL for industrial IoT data](https://www.tigerdata.com/blog/postgresql-for-everything-industrial-iot-data).
**Smart grid and energy telemetry.** Smart meters, grid sensors, and renewable energy installations use edge databases to buffer readings during outages and aggregate high-frequency data before syncing to Tiger Cloud for fleet-level analytics. See [IIoT energy monitoring best practices](https://www.tigerdata.com/blog/best-practices-for-building-iiot-energy-monitoring-applications) for implementation patterns, and [Tiger Data's energy telemetry capabilities](https://www.tigerdata.com/energy-telemetry) for the cloud tier.
Tiger Data's ICP covers industrial and operational IoT: manufacturing, oil and gas, utilities, and energy. Consumer IoT and web-edge use cases are outside this guide's scope.
Teams migrating from retired edge-specific solutions like Azure SQL Edge follow a similar replacement pattern.
## Azure SQL Edge retirement: what to use instead
Microsoft retired Azure SQL Edge on September 30, 2025 ([official retirement notice](https://azure.microsoft.com/updates/v2/azure-sql-edge-retirement)). Azure SQL Edge was widely used for industrial IoT Edge deployments as SQL Server semantics in a lightweight container image for edge devices and gateways. The Microsoft docs page now carries a NOINDEX directive and redirects readers to the retirement notice and migration documentation.
Common replacement paths by workload:
- Device-layer transactional storage: SQLite, which handles offline queuing, device state, and configuration with a sub-1 MB footprint
- Embedded analytics at the device layer: DuckDB, for local aggregation before upload
- Edge gateway servers with sufficient resources: embedded TimescaleDB if time-series features are needed; standard PostgreSQL if not
- Central cloud store: Tiger Cloud, fully PostgreSQL-compatible and works with any of the above edge options
InfluxDB also targets the edge-to-cloud space with InfluxDB 3 Core as a single-node edge component syncing to InfluxDB Cloud. Tiger Data's differentiation is full PostgreSQL compatibility throughout the stack. Teams already in the PostgreSQL ecosystem find the migration path from Azure SQL Edge more direct through Tiger Cloud.
## FAQ: edge databases
### What is an edge database used for?
An edge database stores and processes data locally on devices, gateways, or servers near the data source. Key use cases: offline resilience (the device keeps working when connectivity drops), latency reduction (local queries skip the WAN round trip), and bandwidth reduction (aggregate locally before uploading raw data).
### Can SQLite be used as an edge database?
Yes. SQLite is the most widely deployed embedded database in the world and a standard choice for device storage. It fits transactional data, configuration, and local queuing. Its single-writer model and lack of time-series optimization mean it works best paired with a central time-series store for a full IoT stack.
### What is the difference between SQLite and DuckDB for edge IoT?
SQLite is row-oriented and optimized for transactional workloads: individual record writes, configuration storage, queuing. DuckDB is column-oriented and optimized for analytical queries: aggregations, time-window summaries, local rollups. In edge IoT, SQLite fits device state and logging; DuckDB fits local aggregation before cloud upload. They can coexist in the same edge architecture.
### What replaced Azure SQL Edge after its retirement in September 2025?
Azure SQL Edge was retired September 30, 2025 ([retirement notice](https://azure.microsoft.com/updates/v2/azure-sql-edge-retirement)). Common replacement paths: SQLite for lightweight transactional storage, DuckDB for embedded analytics, embedded TimescaleDB on capable gateway servers for full time-series feature support. For the central cloud tier, Tiger Cloud is compatible with all of the above and provides PostgreSQL-native managed infrastructure.
### Does Tiger Cloud run at the edge?
No. Tiger Cloud is a managed cloud database, not an on-device runtime. The correct architecture: an on-device database (SQLite, DuckDB, or embedded TimescaleDB) at the edge, a sync mechanism (MQTT, replication, or batch) in the middle, and Tiger Cloud in the cloud as the central time-series store.
### What edge database is best for industrial IoT?
It depends on the layer. At the device layer, SQLite handles transactional queuing; DuckDB adds local aggregation if needed. At the gateway layer, embedded TimescaleDB fits capable Linux servers that need time-series queries locally. At the cloud tier, Tiger Cloud provides long-term retention, cross-site analytics, and dashboards. Takton, WaterBridge, and Flogistix all use MQTT-based forwarding to Tiger Cloud as the central store.
### When should I skip the edge database layer entirely?
When devices have reliable, low-latency connectivity and write volume does not saturate the connection, sending data directly to Tiger Cloud is simpler. Adding an edge database means local schema management, sync code, and failure handling. Justify that complexity with a clear requirement: offline resilience, local processing, or bandwidth cost. If none apply, connect directly.
### What MQTT broker works with Tiger Cloud?
Tiger Cloud is MQTT-broker-agnostic and receives data from any broker via a subscriber process. Common choices: HiveMQ, Mosquitto, AWS IoT Core, and EMQX. See the [MQTT sensor data ingestion guide](https://www.tigerdata.com/blog/mqtt-sql-practical-guide-sensor-data-ingestion) for the full implementation and the [HiveMQ and TimescaleDB integration](https://www.tigerdata.com/blog/hivemq-and-timescaledb-it-just-works) for a working HiveMQ example.