Designing IIoT Ingest That Survives a Cut Uplink
Blog post from Tiger Data
A resilient IIoT reconnect design for PostgreSQL and TimescaleDB uses a stable per-reading identity composed of site, device, channel, and device timestamp, enforced by a unique hypertable constraint and idempotent inserts so retransmitted batches cannot create duplicates. Gateways durably buffer readings in SQLite using WAL mode and a high-water mark that advances only after the PostgreSQL transaction commits, allowing safe retries after uncertain network failures. Replays are sent in ordered batches through a temporary staging table because COPY does not support conflict handling directly, then inserted with `ON CONFLICT DO NOTHING`; a separate replay role, connection limit, and per-site rate cap prevent catch-up traffic from severely reducing normal ingest capacity. The approach also accounts for columnstore timing, refreshes continuous aggregates only across the affected historical range, and monitors each site’s replay lag and silence. Validation compares edge-buffer counts, logged replay totals, and stored rows, while example benchmarks show that limiting replay speed substantially reduces its impact on live ingestion.
No tracked trend matches for this post yet.
Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.