TL;DR:
- DittoLive is a sync SDK (not a server) that lets apps share data directly between devices using Bluetooth, Wi-Fi Direct, LAN, and the cloud as fallback — in that order of preference
- Data is stored locally in a document store on each device; sync uses CRDTs (conflict-free replicated data types) to merge concurrent writes without conflicts
- Designed for environments where cloud connectivity is intermittent, expensive, or prohibited — retail stores, hospitals, manufacturing floors, field operations
The Offline Problem at the Edge
Most mobile and IoT applications are designed for the cloud-first assumption: your device connects to the internet, fetches state from a server, and pushes updates back. This works well when connectivity is reliable. In practice, many of the most operationally critical environments are exactly where it doesn’t work:
- Hospital wards with spotty Wi-Fi coverage and strict network segmentation
- Retail shop floors during peak hours when shared WiFi becomes congested
- Oil and gas field sites with satellite-only connectivity
- Manufacturing plants with legacy OT network isolation
- Aircraft with limited or expensive in-flight connectivity
- Emergency response scenarios where infrastructure is degraded
The standard answer has been to build offline caches with sync-on-reconnect. The problem is conflict resolution: when two devices both write to the same record while disconnected, you need to merge those writes correctly. That merge logic is notoriously hard to write correctly and tends to get implemented incorrectly or skipped entirely (last-write-wins, which loses data).
DittoLive addresses this with CRDTs as the fundamental data model, and peer-to-peer transports as the primary sync path.
How DittoLive Works
Local document store: Each device running the Ditto SDK has a local database that stores documents in collections, similar to a local MongoDB. Reads and writes are local — no network round trip required. This means the application is fully functional with zero connectivity.
CRDT-based data model: Documents use CRDT semantics. Registers support last-write-wins (with vector-clock timestamps rather than wall-clock time), counters support increment operations that merge correctly across concurrent updates, and maps support nested CRDT types. The key property: any two replicas of the same document can be merged in any order and arrive at the same result. There are no conflicts to resolve — the merge is deterministic.
Mesh transport stack: When two devices come within range of each other, Ditto establishes a peer connection using whatever transports are available: Bluetooth Low Energy for short range, Wi-Fi Direct for higher bandwidth, or local LAN if both devices are on the same network segment. Sync happens automatically over the peer connection. The cloud connection (Ditto’s managed infrastructure or a self-hosted cloud endpoint) is used as a relay for devices that can’t reach each other directly, and as an authoritative sync log.
Subscriptions and queries: Applications subscribe to collections with queries, and receive live updates whenever matching documents change — whether from a local write, a peer sync, or a cloud sync. The application code doesn’t distinguish between these.
Architecture Patterns
Pure peer-to-peer (air-gapped): For environments where no cloud connection is permitted, Ditto operates without the cloud component. Devices sync only when they’re in proximity. This is useful for industrial OT networks, classified environments, and any scenario where data must not leave the facility. Sync completeness depends on device proximity patterns — if every device occasionally encounters an “always-on” edge node (a tablet at a workstation, a Raspberry Pi on the shop floor), that node can serve as a hub for data exchange between devices that never meet directly.
Peer-to-peer with cloud fallback: The most common deployment. Devices sync locally when available, cloud handles sync for devices that are geographically separated or currently not in proximity. Cloud also provides durability — if a device is lost or reset, it can recover full state from the cloud endpoint.
Hub-and-spoke at the edge: Dedicated edge nodes (Raspberry Pi, industrial gateway, server) run Ditto as always-on peers, acting as local hubs for device sync. Useful for retail stores or manufacturing cells where you want sync to be fast and local but devices may come and go throughout a shift.
SDK and Platform Support
DittoLive provides native SDKs for:
- Swift / SwiftUI (iOS, iPadOS, macOS)
- Kotlin / Jetpack Compose (Android)
- JavaScript / TypeScript (React Native, Node.js, Electron)
- C++ (Linux, Windows, embedded)
- Rust (embedded, edge nodes)
- C (for deeply constrained MCU environments via a thin wrapper)
The data model is consistent across platforms — a document written on an iOS device merges correctly with one modified on Android or a Linux edge gateway.
When to Choose DittoLive
DittoLive fits well when:
- Your application must work without connectivity and sync is operationally critical (inventory, patient records, inspection reports, work orders)
- Devices are physically co-located and peer sync is faster and cheaper than cloud round-trips
- You have compliance requirements that restrict cloud data residency
- Your edge nodes are resource-constrained and you can’t run a full database server
It’s not the right choice for:
- Applications with purely server-authoritative data models (financial transactions, anything requiring a global single source of truth)
- Simple online CRUD applications where offline support isn’t needed
- Teams comfortable with conflict resolution logic who already have an offline-sync layer in their stack
Comparison to Alternatives
Firebase Realtime Database / Firestore: Cloud-first, Google infrastructure required, no peer-to-peer mode. Good offline caching but sync goes through Google’s cloud regardless of device proximity.
Realm / Atlas Device Sync: Mobile-first document database with sync via MongoDB Atlas. No peer-to-peer transport — cloud connectivity required for sync. Strong developer experience; less suitable for airgap scenarios.
CouchDB / PouchDB: Open-source CRDT-like replication via CouchDB protocol. Peer-to-peer possible but requires running CouchDB instances as sync endpoints. More operational overhead; no managed SDK with Bluetooth/Wi-Fi Direct transports.
Custom CRDT implementation: Libraries like Yjs and Automerge provide CRDT primitives for building your own sync layer. More flexible but requires significant engineering to handle transports, conflict edge cases, and operational concerns.
DittoLive’s differentiation is the transport stack — Bluetooth LE and Wi-Fi Direct are handled by the SDK without custom code. For teams that need offline-first sync and don’t want to build the transport and merge layers from scratch, it substantially reduces implementation complexity.
Practical Considerations
Licensing and pricing: DittoLive is commercial software with a free tier for development and small deployments. Production deployments are licensed per device or per monthly active device. Evaluate the commercial terms against build-vs-buy for your scale.
Data model constraints: The CRDT approach requires thinking about data model design upfront. Operations that are naturally non-commutative (transfer $X from account A to account B) don’t map directly to CRDTs. DittoLive works best for append-heavy patterns (sensor readings, status updates, log entries) and document stores where concurrent field updates are acceptable.
Bluetooth power consumption: Continuous Bluetooth LE advertising for peer discovery affects device battery life. DittoLive provides configuration options for scan and advertising intervals; more aggressive settings enable faster peer discovery at the cost of battery drain. Calibrate for your device class.
Regulatory considerations: Some healthcare and financial applications have data handling requirements that affect where sync traffic can flow. Ditto’s self-hosted cloud option (rather than managed cloud) is relevant for these deployments.