Why MobyDB How it works MobyQL Use cases Deploy GitHub ↗ Early access
Built on GEP Protocol · Apache 2.0

Geography is not
a column.
It is the address.

WHERE
H3 cell
WHEN
GEP epoch
WHO
Ed25519

MobyDB is the first database where a hexagonal cell, a cryptographic epoch, and an Ed25519 public key are the primary key. Not columns. The key itself.

48B
Composite key
569T
Addressable cells
Res-15
Sub-metre precision
EPOCH 1 · ROOT 871e8052a epoch: 1 rings: 1 zoom_out() Res-7 → Res-5
The Problem

PostGIS was built for rows.
The world runs on space.

Every existing database stores location as an attribute of a record. MobyDB stores records as attributes of a location. The difference is everything.

Every other database
Geography as afterthought

PostGIS is remarkable engineering on the wrong foundation. PostgreSQL was designed for rows and columns in the 1970s. Geography is a column type bolted on 20 years ago.

  • Primary key is a row ID — geography is a float pair
  • Spatial queries require GiST index + geometry calculations
  • No native time dimension — need TimescaleDB extension
  • No identity model — attribution is application-layer logic
  • Jurisdiction enforcement lives in your code, not the DB
  • Audit trail requires triggers — bypassable, not cryptographic
  • Resolution aggregation needs explicit GROUP BY + boundary tables
MobyDB
Geography as foundation

The primary key IS the location, the time, and the identity. These are not columns. They are the three dimensions of the address space itself.

  • Primary key: (H3 cell, GEP epoch, Ed25519 public key)
  • near() = integer range scan on sorted bytes. No geometry.
  • Time is a GEP epoch — native dimension, not a column
  • Identity is Ed25519 — cryptographic, not a username
  • Access control: requester.h3_cell within territory predicate
  • Merkle epoch chain — tamper-evident, offline-verifiable
  • zoom_out() — H3 resolution IS the aggregation hierarchy
The Spacetime Identity Address

48 bytes. The entire universe of information, addressed.

A MobyDB record doesn't have a primary key. It is a position in spacetime, signed by an identity. WHERE it was created. WHEN it was sealed. WHO signed it. These three facts, together, uniquely address any piece of information that has ever existed.

// 48 bytes · lexicographically sortable
// physical layout in RocksDB:
 
h3_cell : u64 // 8 bytes ← WHERE
epoch : u64 // 8 bytes ← WHEN
public_key: [u8;32] // 32 bytes ← WHO
 
// near() = integer range scan
// no GiST index, no geometry math
Architecture

How MobyDB works.

Five properties that follow naturally from the spacetime identity address. None of them require additional infrastructure. They are consequences of the data model.

Storage
H3 cell colocation
Records are physically stored sorted by H3 cell. All records in the same neighbourhood are adjacent on disk. Geographic locality = storage locality. Proximity queries are sequential reads.
Aggregation
Resolution as zoom
H3's cell hierarchy IS the aggregation hierarchy. zoom_out(resolution: 5) groups Res-9 records by their Res-5 parent. No GROUP BY. No boundary tables. No materialized views. O(1) tree traversal.
Identity
Signature on write
Every write is verified with Ed25519 before RocksDB accepts it. Unsigned records are rejected at the engine level. The database cannot contain unattributed data. Attribution is structural, not optional.
Access control
Geographic predicates
Access policy: requester.h3_cell WITHIN territory("italy"). Not application logic. Not row-level security. The address space enforces jurisdiction. EU data cannot be read from a US cell without a delegation certificate.
Audit
Merkle epoch chain
At epoch close, all records form a Blake3 Merkle tree. The root is sealed and chained to the previous epoch. Any record can prove it existed before the seal — offline, without contacting any server. This is not a log. It is a proof.
Compliance
Proof on demand
GET /proof/:cell/:epoch/:pubkey returns a Merkle path bundle. Present it to a NIS2 auditor, an EU AI Act inspector, or a court. It proves: this data existed, at this location, at this time, signed by this identity. No third party required.
Query Language

MobyQL — three operators
replace spatial SQL.

MobyQL is not SQL with geographic extensions. Space and time are operators, not functions called on columns.

Proximity query
Aggregation
Jurisdiction + compliance
Proof generation
// Find all voltage anomalies near Palermo — last 3 epochs
// No geometry calculation. No GiST index. Just integer range scans.

near("8a1e805xxxxxxxx", rings: 2)
  .during(epoch: current-3, current)
  .collection(Telemetry)
  .where(payload.voltage_delta > 10.0)
  .with_tier(TrustTier::Certified)
  .execute(&store)?;

// PostGIS equivalent requires:
// ST_DWithin() + BETWEEN timestamp + JOIN trust_tier + HAVING
// Four concepts. Four joins. One PostGIS query plan.
// MobyQL: one chained statement. One range scan.
// District-level voltage averages from building-level sensors
// zoom_out() is the GROUP BY killer

ZoomQuery::new(
  source_cells: palermo_res9_cells,
  epoch: 9,
  target_resolution: 5,  // Res-9 → Res-5 metro aggregation
  aggregation: AggregationType::Average,
  value_path: "sensor.voltage.reading",
).execute(&store)?;

// H3 parent traversal: O(1) per record
// No GROUP BY. No boundary tables. No materialized views.
// The H3 hierarchy IS the aggregation hierarchy.
// zoom_out(5) === aggregate to metro level. Always.
// All critical events in Italy, last 24h, by Terna-certified devices
// Jurisdiction is an address predicate — not application logic

territory("italian_nis2_zone")     // H3 cell set for Italy
  .during(epoch: 8, 10)
  .by(delegated_by: "@terna-admin")  // GNS-AIP delegation
  .collection(Event)
  .where(payload.severity == "critical")
  .execute(&store)?;

// Result set is:
// ✓ Jurisdictionally proven (Italy only, by address)
// ✓ Cryptographically attributed (Terna delegation chain)
// ✓ NIS2 compliant (time-bounded, signable)
// ✓ EU AI Act Art.12 ready (full audit trail)
// Generate offline-verifiable proof for any record
// The result bundle proves: who, where, when — without any server

let proof = engine.generate_proof(&SpacetimeAddress {
  h3_cell:    0x871e8052affffff,   // Rome Res-7
  epoch:      1,
  public_key: camilo_pubkey,
})?;

// proof.verify() → true
// proof.record_hash == proof.epoch_root (single-leaf: path = [])
// proof.epoch_root == dfee521a...d831

// To verify offline:
// 1. hash(canonical_record_bytes) == record_hash ✓
// 2. walk path to epoch_root ✓
// 3. epoch_root matches published GEP chain hash ✓
// Done. No server. No trust anchor. Pure math.
Use cases

Built for the data that
existing databases cannot describe.

Every dataset that is fundamentally WHERE + WHEN + WHO. Every database that currently handles this with three systems and an application layer in between.

569T
Pilot: Terna S.p.A.
Energy & IoT
Grid telemetry with Merkle proofs
Voltage sensors write signed readings to their H3 cell at every epoch. GEIANT AI agents query near() for anomalies. Engineers issue signed commands. Everything chains to a Merkle root. NIS2 audit report is a single API call.
Before: InfluxDB + PostGIS + custom audit system.
After: MobyDB. One write. One query. One proof.
GNS
Native protocol
Identity & Trajectory
GNS Proof-of-Trajectory
A GNS breadcrumb is a signed record at an H3 cell in an epoch. That is exactly MobyDB's native record type. The breadcrumb chain IS a MobyDB trajectory query. Identity is not stored — it is proven, epoch by epoch, cell by cell.
GNS handles: from Supabase varchar → MobyDB spacetime address.
The handle is the pointer. MobyDB is the proof.
AIP
EU AI Act
AI Compliance
EU AI Act audit trails
Every GEIANT inference session has a location (worker H3 cell), a time (epoch), and an identity (agent public key). Storing this in MobyDB provides EU AI Act Art. 12/14 traceability as a database primitive — not a compliance tool bolted on top.
August 2, 2026 deadline: MobyDB sessions are compliant by construction. Not by configuration.
H3
Smart cities
Urban mobility & environment
City-scale spatial analytics
Millions of GPS points per hour from vehicles, sensors, drones. PostGIS at this scale requires dedicated DBA teams. MobyDB: one write per H3 cell transition. zoom_out(5) gives city-level aggregates instantly. Resolution IS the dashboard level.
zoom_out(resolution: 5): building → district → metro in one operator. No pipeline. No refresh job.
Deployment

Apache 2.0 core.
Run it anywhere.

MobyDB is a Rust binary. No JVM. No runtime. No cluster required to start. One command.

Rust
No GC pauses at epoch close
RocksDB
LSM-tree, battle-tested at Meta scale
Blake3
Merkle hash — 10× faster than SHA-256
h3o
Pure Rust H3 — zero C FFI
OSS

MobyDB Core

Apache 2.0 — free forever
  • mobydb-core Spacetime address, composite key, record types
  • mobydb-storage RocksDB engine, signature verification on write
  • mobydb-merkle Epoch sealing, Blake3 tree, proof generation
  • mobydb-query MobyQL: near(), during(), zoom_out()
  • mobydb-server axum HTTP API — 9 endpoints, runs on Railway
  • Single binary: mobydbd serve --port 7474
  • Embeddable: Dart FFI / WASM for Flutter / browser

MobyDB Cloud

Managed · Jurisdiction-native · Coming 2027
  • Sharded by H3 Res-3 — Italian data on Italian nodes by default
  • Multi-region with GEP-anchored epoch synchronization
  • NIS2 incident report endpoint — one API call
  • EU AI Act Art. 12/14 compliance dashboard
  • Managed epoch sealing — Merkle roots published hourly
  • 99.9% SLA · Dedicated CSM · Custom MSA
  • Per-cell-epoch pricing — not per row, not per byte
GEP
Built on GEP Protocol. The same cryptographic fabric that powers GNS identity, GEIANT Hive compute, and GCRUMBS messaging. github.com/GNS-Foundation/mobydb →
Protocol Stack

MobyDB in the GNS stack.

Every layer of the GNS Protocol produces data that belongs in MobyDB. Every query MobyDB answers feeds the layers above it.

L4
GCRUMBS
Human + AI + IoT messaging
reads proofs
L3
GEIANT Hive
Distributed AI inference · agent sessions
writes sessions
L2
GNS-AIP
Agent identity · delegation certificates
writes certs
L1
GNS Protocol
Ed25519 identity · Proof-of-Trajectory
writes breadcrumbs
DB
🐋 MobyDB
Spacetime identity address · Merkle epoch chain
native store
L0
GEP Protocol
H3 hexagonal grid · epoch chain · genesis hash
the fabric
GEP Genesis
26acb5d998b63d54f2ed92851c5c565db9fe0930fc06b06091d05c0ce4ff8289
c(r) = 2 + 120 × 7ʳ  ·  Res-15: 569,707,381,193,162 cells  ·  One square metre. Addressed.

Early access.

MobyDB is in active development. We are working with a small number of enterprise partners in energy, utilities, and AI compliance to validate the model in production. Describe your use case.

🐋

We received your request.

A member of our team will reach out within 24 hours.
In the meantime, explore the code at github.com/GNS-Foundation/mobydb.

No pitch decks. No sales process. Direct conversation about your data.