Couchbase · Use case
IoT data management: keeping device data useful from the site to the centre
IoT data management is the work of storing, moving, checking, querying and retiring the data that sensors, machines and connected devices produce. The hard part is rarely volume alone: it is sites with weak links, readings that arrive late or twice, and rules on where the data may live. This guide covers the problem in plain words, the design options and their trade-offs, the pattern Couchbase describes for edge and mobile sync, and where it fits.
Published 9 min read
Orientation
At a glance
The guide in one table, before the detail.
- What it covers
- Storing, syncing, querying and retiring the data that devices and sites produce
- The usual difficulty
- Weak links, late and repeated readings, and growing volume
- The Couchbase pattern
- Couchbase Lite on devices, Edge Server at sites, Sync Gateway or App Services, and a central cluster
- Where the centre can run
- Couchbase Capella, including the Dammam region, or self-managed Couchbase Server in the Kingdom
- What Interkey does
- The database layer: design, deployment and support from Riyadh
In short, for executives
- The problem: devices produce data in many places, often where the network is weak, and the business needs it in one place it can trust.
- What goes wrong: readings lost when a link drops, readings that cannot be matched to an asset, and storage that grows with no plan to retire it.
- The main choice: send everything straight to the centre, or keep data at the site and sync it when the link allows.
- Where Couchbase fits: device and site data that must keep working offline and sync both ways with a central document database.
- Where it does not: a pure stream of high-rate metrics analysed only in aggregate, or sites with a dependable link and simple needs.
What IoT data management means, and why it is hard
Every connected device produces records: a temperature reading, a meter value, a door event, a vehicle position, a machine's status. IoT data management covers what happens to those records from the moment they are created: where they are stored first, how they reach the systems that use them, how they are checked and tied to the asset they describe, who may read them, and when they are summarised or deleted.
Read more
Three things make it harder than an ordinary application database:
- The network is not always there. Plants, remote sites, warehouses and vehicles lose their links. Anything that waits for the centre stops when the link does.
- Data arrives out of order. A device that was offline sends an hour of readings at once, and a retry can send the same reading twice. The design has to accept both without corrupting the record.
- Volume only grows. Without a decision on what to keep in full, what to summarise and what to expire, storage cost and query time climb every day.
Most of the effort sits in these decisions, not in the choice of product.
Why it matters in Saudi Arabia
In the Kingdom the question usually arrives with a programme: industrial sites and utilities adding sensors to plant, logistics operators tracking fleets, facilities teams connecting buildings, and field teams working where coverage is thin.
Two Saudi questions shape the design early. Where may the data live? Many organisations must keep certain data inside the Kingdom under the National Cybersecurity Authority's controls (nca.gov.sa) and the Personal Data Protection Law overseen by SDAIA (sdaia.gov.sa); a copy at the edge is still a copy. Who will run it after go-live? Interkey supports the database layer from Riyadh, with engineers who work in Arabic and English.
Relatednca.gov.sasdaia.gov.sa
Design options and their trade-offs
Four common designs, described by how they behave rather than by product.
| Design | How it works | Where it fits | The trade-off |
|---|---|---|---|
| Send everything to the centre | Devices or gateways write each reading straight to a central database or service | Sites with a dependable link, and readings that can wait for it | Readings are lost or queued on the device when the link drops, and the centre carries the whole load |
| Store at the site, sync to the centre | A database on the device or site gateway keeps working offline and exchanges changes when a link exists | Remote sites, plants and vehicles that must keep recording and reading locally | More to design: what each site holds, how changes merge and who sees what |
| Batch files loaded later | Readings are collected in files and loaded on a schedule | Reporting that can wait hours or a day | No current view, and errors surface long after the reading was taken |
| Raw short-term, summaries long-term | Recent readings are kept in full and expire on a timer; older data survives as summaries | Any design above where volume grows every day | The summary rules must be agreed with the people who use the data before raw readings expire |
The options combine. Most real designs store at the site, sync to the centre and retire raw readings on a schedule.
IoT data management with Couchbase: the pattern Couchbase describes
From Couchbase's own descriptions of its products.
| Tier | What runs there | What Couchbase states |
|---|---|---|
| Device or app | Couchbase Lite | An embedded NoSQL JSON document database for mobile and edge devices; it stores, syncs and queries data locally, even without network connectivity |
| Site or gateway | Couchbase Edge Server | A lightweight standalone database for resource-constrained edge locations, which can serve local Couchbase Lite clients and sync with upstream services |
| Sync layer | Sync Gateway, or Capella App Services as the managed version | Bi-directional sync between edge devices and the cloud, with access control through users, roles and channels |
| Centre | Couchbase Capella or self-managed Couchbase Server | The central JSON document database, with SQL++ queries, search, analytics and eventing services on the same data |
Our edge database page covers the site tier in more depth, and the offline sync page covers devices and apps. Confirm supported platforms and versions on Couchbase's pages before you design around them.
Designing the data: documents, channels, conflicts and expiry
With the tiers chosen, most of the work is the data design. We settle these decisions with your team, from Couchbase's documentation:
Read more
- Documents shaped by the asset. Couchbase stores JSON documents that are fetched by key and queried with SQL++. A common start is one document per device for its profile and state, with readings in documents of their own, grouped so the queries the business runs stay simple. Our NoSQL database page explains how a document database differs from the other types.
- Channels decide what each site holds. Sync Gateway and App Services control access through channels, and a device can limit its pull to chosen channels, so a site holds only its own assets' data.
- A rule for conflicts. When a record changes in two places, Couchbase Lite resolves it on pull: by default a deletion wins, otherwise the revision with the most revisions; a custom resolver can apply your rule. Readings are usually written once and rarely conflict; asset state and work orders do.
- Expiry for raw readings. Couchbase can expire documents on a timer, so raw readings are retired after the agreed period while their summaries remain.
- Reacting and analysing. Eventing, which acts when data changes, and Analytics run as services of their own, so heavy work can be given nodes that do not slow the operational queries.
Questions to settle before choosing a design
- What must keep working with no link, and for how long: recording, reading, or both.
- What each site or device needs to hold.
- How a reading is tied to its asset: device identity, the asset register, and what happens when a device is replaced.
- How late or repeated readings are handled, so a retry never counts twice.
- How long raw readings are kept, and which summary replaces them.
- Where every copy lives: devices, sites, the centre, backups and logs, against your data classification.
- Who maintains software at many sites after go-live: updates, monitoring and spare hardware.
Where Couchbase fits for device data, and where it does not
It fits when device or site data must keep working offline, sync both ways with a central database, and be read as documents by applications: field apps, site systems, asset state, inspections and work orders alongside the readings.
It may not be the first choice when the data is only a high-rate stream of time-ordered metrics analysed in aggregate; a database built for time-series data can suit that better, as our types of databases guide explains. If every site has a dependable link and simple needs, a central database alone is simpler.
Interkey does not supply sensors, devices or connectivity. Our part is the data platform behind them, as a Couchbase technology partner that sells Couchbase Capella.
Relatedtypes of databases guide
How Interkey delivers an IoT data management project
-
Workload review.
Sites and devices, how often links drop, what each location must keep working, volumes, retention and the residency rule. "A central database is enough" is a legitimate outcome.
-
Data and sync design.
Documents and keys, channels per site, the conflict rule per record type, expiry for raw readings and the summaries that replace them.
-
A pilot at real sites.
A few devices or sites on the proposed design, with links cut on purpose to test recording, sync and conflicts.
-
Build the centre.
Capella in the agreed region or Couchbase Server on your infrastructure, with replicas and, where needed, a recovery site.
-
Roll out site by site.
Existing data moved where needed, usually with iblync, Interkey's own product; sites join in waves, with a tested way back.
-
Operate or hand over.
Monitoring, upgrades and capacity reviews under a written managed-services scope, or a documented handover to your team.
Where it runs and what drives the cost
Couchbase Capella is the vendor's managed service on AWS, Google Cloud or Microsoft Azure. As of 2 November 2026 its published regions include Google Cloud's Dammam region (me-central2), and Couchbase's region list shows App Services available there. Self-managed Couchbase Server runs on infrastructure you control, such as your own data centre in the Kingdom. Our Capella or self-managed page compares the two.
Read more
We publish no price or duration. What moves the number: how many sites and devices, the data each holds, how long raw readings are kept, replicas and a recovery site, and the sync layer chosen. Capella is billed per node per hour; self-managed Couchbase Server is a subscription priced by production nodes. Our work is quoted on its own lines.
RelatedCapella or self-managed page
Questions buyers ask
What does IoT data management involve beyond storing sensor readings?
The whole life of the data: where it is first written, how it reaches the centre, how it is tied to the asset it describes, who may read it, and when it is summarised or deleted.
Can a site keep recording device data when its link to the data centre drops?
Yes, if the data is stored at the site. With Couchbase, Couchbase Lite or Edge Server keeps working locally, and the replicator retries until the link returns, then exchanges the changes.
Is a NoSQL document database a sensible home for IoT data?
For device profiles, asset state, inspections and readings that applications read, often yes, because each record keeps its own shape. For a pure stream of high-rate metrics analysed only in aggregate, a time-series store may suit better.
Can device data from sites in Saudi Arabia stay inside the Kingdom?
Yes. Couchbase Server can run in your own data centre in the Kingdom, and as of 2 November 2026 Capella's published regions include Google Cloud's Dammam region. Edge copies, backups and logs count too.
How is a Couchbase platform for IoT data priced in KSA?
Capella is billed per node per hour, and Interkey sells it; self-managed Couchbase Server is a subscription by production node. The size depends on sites, data held, retention and replicas. Our work is quoted separately.
How long does it take to roll a device data design out across many sites?
It depends on the number of sites, how far the current data is from the new design and how the rollout waves are planned. We estimate it after the workload review and a pilot, not before.
Next
Related pages
Next step
Review your IoT data design
Tell us how many sites or devices you run, how often their links drop, what each must keep working, how long readings are kept and where the data must stay. We will reply with a first view and the next step.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia