Edge Computing with HeliosDB Nano

Editor's note — October 2026. Corrections against Nano 4.41.0. The Product Quantization option is WITH (quantization = 'product') (the sample below now uses it), and the recall-safe default saves about 16× resident RAM (internal tests, Nano 3.32.1 vs an unquantized index, see benchmarks.html), not 384×. The 4.41.0 release binaries are about 36-44 MB, depending on platform (~15-17 MB compressed download). Branch MERGE is last-writer-wins with no conflict detection. The default build replicates to a warm standby with manual switchover; multi-primary and sharded replication are planned. The server starts with heliosdb-nano start --data-dir <dir>.

HeliosDB Nano is our smallest edition — a single Rust crate that compiles to a compact binary and brings the full power of HeliosDB to edge devices, embedded systems, and mobile applications. Today we're exploring why edge computing needs a real database (not just SQLite) and how Nano delivers.

Why Not SQLite?

SQLite is an incredible piece of software. But it was designed for single-process embedded use in 2000. Modern edge applications need capabilities that SQLite fundamentally doesn't provide:

| Capability              | SQLite | HeliosDB Nano |
|-------------------------|--------|---------------|
| Vector search (HNSW)    | No     | Yes           |
| Time-travel queries     | No     | Yes           |
| Database branching      | No     | Yes           |
| Replication (HA)        | No     | Warm standby  |
| PostgreSQL protocol     | No     | Yes           |
| Product Quantization    | No     | Yes           |
| MVCC                    | WAL-based | Full MVCC  |
| Concurrent writers      | 1      | Many          |
| Column encryption       | No     | AES-256-GCM   |

Nano Architecture

Unlike HeliosDB Full (193 crates) or Lite (1 crate + proxy), Nano is a single monolithic crate containing ~188K lines of Rust. This minimizes binary size and eliminates inter-crate overhead:

heliosdb-nano/
  src/
    storage/     -- RocksDB backend, branch manager, MVCC
    sql/         -- SQL parser, planner, executor
    vector/      -- HNSW index, Product Quantization, SIMD
    protocol/    -- PostgreSQL wire protocol
    replication/ -- HA Tiers 1-3, branch replicator
    api/         -- REST API, data/query handlers
    crypto/      -- AES-256-GCM, ChaCha20, key derivation

Edge Deployment Patterns

IoT Gateway: Deploy Nano on a Raspberry Pi or similar edge device. Collect sensor data locally, run real-time analytics with SQL, and synchronize to a central HeliosDB Lite or Full cluster when connectivity is available.

# Deploy on ARM64 edge device
cargo build --release --target aarch64-unknown-linux-gnu \
    --features server,encryption,vector-search

# Run as embedded server
./heliosdb-nano --port 5432 --data-dir /var/lib/helios

# Or embed directly in your Rust application
use heliosdb_nano::Database;
let db = Database::open("/var/lib/helios")?;
db.execute("CREATE TABLE sensors (id INT, value FLOAT, ts TIMESTAMP)")?;

Mobile Offline-First: Embed Nano in your mobile application for offline data access. Branch the database for offline work, then merge changes when connectivity returns.

-- On the device (offline)
CREATE BRANCH offline FROM main;
USE BRANCH offline;
INSERT INTO orders (product_id, quantity) VALUES (42, 3);

-- When connectivity returns
MERGE BRANCH offline INTO main;
-- Last writer wins: there is no conflict detection

AI at the Edge: Run vector search locally on edge devices. Product Quantization keeps the index small: about 16× less resident RAM at recall-safe defaults (internal tests, Nano 3.32.1 vs an unquantized index, see benchmarks.html):

-- Create vector index on edge device
CREATE TABLE local_embeddings (
    id INT PRIMARY KEY,
    doc TEXT,
    embedding VECTOR(384)
);

CREATE INDEX ON local_embeddings USING hnsw (embedding)
    WITH (quantization = 'product');

-- Semantic search runs entirely on-device
SELECT doc FROM local_embeddings
ORDER BY embedding <=> $1
LIMIT 5;

Replication for Edge

Nano's default build replicates to a warm standby (multi-primary and sharded replication are planned):

# Edge device configuration
[replication]
role = "standby"
primary_host = "cloud.heliosdb.example.com"
primary_port = 5432
sync_mode = "async"  # Async for intermittent connectivity

Feature Flags

Nano uses Cargo features to control binary size. Enable only what you need:

[features]
server = ["tokio/full"]           # Standalone server mode
encryption = ["aes-gcm", "ring"]  # TDE/ZKE
vector-search = []                # HNSW + PQ
sync-experimental = []            # Replication

HeliosDB Nano is open source (Apache 2.0) and available on GitHub. It's the smallest way to get PostgreSQL-compatible, AI-native database capabilities on any device.

← Back to Blog