Architecture Overview

This is the page to read first before JDBIN, JDBON, R2 + Worker Runtime, and the comparisons with other systems.

30-second answer

The most interesting difference in this architecture is not just a new binary format. The real difference is that the query path is built around Cloudflare Worker and R2 Object Storage without a separate database server.

Core idea in one diagram

Client
  -> Cloudflare Worker
  -> query planner
  -> range reader
  -> R2 object
  -> JDBIN / JDBON
  -> JSON response

The Worker does not load the whole object. It fetches only the required byte ranges from R2.

What is different from a traditional database model?

Many traditional architectures look like this:

Disk
  -> database process
  -> query engine
  -> client

There, the database process owns the disk, the query optimization, and the execution.

This model starts somewhere else:

Object Storage (R2)
  -> HTTP Range GET
  -> Cloudflare Worker
  -> planner
  -> JSON

Side-by-side at a glance

Traditional DB model

Client
  -> SQL query
  -> database process
  -> optimizer / execution engine
  -> local disk pages
  -> rows back to client

Typical characteristics:

• the database process owns the disk
• the query engine and execution live in the same server process
• the disk is read from the database's own runtime context
• object storage is not the primary read layer

R2 + Worker + JDBIN model

Client
  -> HTTP request
  -> Cloudflare Worker
  -> query planner
  -> HTTP Range GET
  -> R2 object
  -> JDBIN segments
  -> JSON response

Typical characteristics:

• the canonical data lives in object storage
• the Worker acts as the query engine at the public interface
• reads happen as byte ranges instead of loading the whole object
• no separate database server is required as its own layer

Comparison table

In other words:

• the canonical storage layer is object storage
• the query logic lives in the Worker
• reads happen as byte-range fetches
• the final result is delivered as a snapshot or JSON response to the UI

Why is Cloudflare central here?

Cloudflare is not just the hosting layer here. It is part of the architecture itself.

The key primitives are:

• R2, which acts as the canonical immutable object storage layer
• Worker, which acts as the query planner, range reader, parser, and response assembler
• HTTP Range GET, which allows selective reads without loading the whole object
• the edge runtime, which keeps the query path close to the public interface

What do JDBIN and JDBON do in this split?

In simplified form:

• JDBIN is the read-optimized binary data artifact
• JDBON is the publication, manifest, and control layer
• Worker decides which parts need to be read
• R2 stores the active state, bases, deltas, and snapshots

That means the read path and the publish path are intentionally separated.

What does this not mean?

This should not be described as if it were already a general SQL database or a full database engine.

The safe current boundary is:

• no general SQL parser
• no general execution engine for everything
• no general-purpose OLTP database
• no traditional database server that owns both disk and execution

What makes this an interesting research question?

The research question is not just "can a binary format store data", but:

Can immutable object storage act as a queryable read layer without a separate database server, if known query paths are implemented in a Worker through byte-range reads?

Recommended reading order

1. JDBIN
2. JDBON
3. R2 + Worker Runtime
4. Comparison with Other Systems

Safe closing formulation

The real novelty of the architecture is not only the format, but that Cloudflare Worker acts as the query engine on top of an object-storage-native R2 layer without a separate database server.