A MODERN, DISAGGREGATED DATABASE.OPEN SOURCE / BUILT IN RUST
Rockbee Console · Enterprise · Coming soon

Simple by key.
Powerful
with SQL.

Store application data by key. Query JSON with SQL. Keep durable data in object storage, and scale your readers as your application grows.

Rust client. SlateDB persistence. DuckDB queries.

Independent compute. One shared foundation.A writer and two independent readers connect to one shared object store. The writer uses SlateDB; readers serve lookups and DuckDB SQL. COMPUTE / INDEPENDENT01 — 03 WRITERREADER+ READER SHAREDDURABLE
Keep the data. Choose the compute.One shared S3-compatible store
01 Opaque byte values02 Flexible JSON tables03 Real DuckDB SQL04 Independent readers

01 / THE INTERFACE

Look up by key.
Explore with SQL.

Product catalogs, application content, or saved model outputs. Use one client to fetch a record by key and query JSON fields with SQL.

ROCKBEECLIENT / RUST
SCHEMA-FREE DOCUMENTS

Your fields.
Your next idea.

Put a JSON object. Get a UUID back. Add different fields to the next document, or use your own ID for a replacement.

  • Nested objects and arrays
  • Generated or caller-supplied IDs
  • Get, replace, delete, and optional TTL
products.rs
let products = client.table("products");

let write = products.put(&json!({
    "name": "Keyboard",
    "price": 99.5,
    "brand": "Logitech"
}));

let id = write.await?; // Durable acknowledgement.
let document = products.get(&id).await?;
Different documents can have different fields. Reads are eventual.

Connect once with RockBeeClient::connect(addr).await?

Run the full SDK example

02 / ROOM TO GROW

More readers.
Same durable dataset.

Read demand and data size are different things. Provision reader compute separately, without a full durable copy of the dataset for each reader.

EXPLORE THE TOPOLOGY
1 reader
WriterSlateDB + Parquet export
Reader 01GET + SQL · local cache
One shared object storeS3-compatible · SlateDB WAL + SST · published Parquet
DATA STAYS HERE
Amazon S3S3 backend available
Cloud StorageNot yet integrated
Blob StorageNot yet integrated
MinIOS3-compatible storage
Custom storageYour S3-compatible endpoint

MinIO or your S3-compatible storage. Connect through the S3 backend. Local development also supports LocalStack and local files. Validate your chosen provider with your workload.

One writer, one reader. Separate processes, shared durable data.

Illustrative topology · readers are configured explicitly
01

Size compute for the work.

Choose writer and reader resources independently. Add read-serving processes as your workload needs them.

02

Keep durable data in place.

A new reader opens the shared dataset and builds its local cache. Durable storage stays separate from the process.

03

Replace a process. Keep going.

Reader compute is replaceable. Metadata loading, catch-up, and cache warmup still take time.

03 / THE FOUNDATION

Independent compute.
Shared durable storage.

Compute serves requests. Object storage keeps durable data. This is disaggregated architecture: size readers for traffic and storage for the dataset, without a full durable database copy for every reader.

01 Gateway
Your client connects here. It sends PUT and DELETE to the writer, and GET and SQL to readers.
02 One writer
Owns mutations for a storage prefix. SlateDB makes writes durable. The writer also uses DuckDB to export JSON table data into Parquet in the background.
03 Independent readers
Serve lookups and queries with their own compute and local caches. Add reader processes as read demand grows.
04 Object storage
Holds shared durable files: SlateDB write logs and data files, plus the Parquet projection used for SQL.
FOLLOW A REQUEST
CLIENTRockBeeClient
ROUTINGGateway
WRITE + EXPORTWriter SlateDB / DuckDB
READ + QUERYReaders SlateDB / DuckDB
DURABLE DATAObject storageS3-compatible · WAL · SST · Parquet
WRITE → DURABLE ACK

Client → gateway → writer. SlateDB persists the mutation in object storage before the writer acknowledges success. Readers catch up independently; the writer publishes the SQL projection in the background.

WHAT THIS MEANS IN PRACTICE

More read traffic? Add reader compute.

Configure another reader against the same storage prefix and include it in the gateway's reader list. It opens the shared dataset and warms its own cache. You do not need a full durable replica for every reader, and adding a reader does not require increasing writer compute.

Reader provisioning is explicit. Catch-up and cache warmup take time; capacity depends on your workload and the rest of the system.

GET / THE ORIGINAL VALUE

SlateDB serves the key.

A reader looks up the byte key or document ID through SlateDB. Its local cache keeps frequently used data close; shared object storage supplies the durable files. Readers follow the writer's updates, so a recent write may not be visible immediately.

Explore the reader
SQL / WRITER + READER

Writer publishes. Reader queries.

DuckDB has a job on both sides. The writer uses it to create Parquet files from JSON table data and publishes those files asynchronously. On a reader, DuckDB runs your SELECT over the published projection and returns JSON rows. The export and the query are separate operations.

Explore the query engine

04 / AI APPLICATIONS

Keep the context.
Query the results.

Your models produce more than answers. Store their outputs, saved context, evaluations, and chat or agent logs. Retrieve by key. Explore with SQL.

INFERENCE IS WORK. KEEP THE RESULT.

Generate once.
Reuse what fits.

A product description. A document summary. A classification. Save a completed output under a key that identifies the model version and input.

When the same result is useful again, your application can fetch it instead of making another model call.

WRITE
Your pipeline stores the completed result.
READ
Your application looks up its model-and-input key.
See the client API
MODEL OUTPUTEXAMPLE DATA
model_outputscatalog-v3:product-42:r7
{
  "model_version": "catalog-v3",
  "input_id": "product-42",
  "input_revision": 7,
  "description": "A compact wireless mouse.",
  "tags": ["wireless", "office"],
  "language": "en"
}
FETCH BY YOUR KEY
let outputs = client.table("model_outputs");
let output = outputs.get("catalog-v3:product-42:r7").await?;

Include input and model versions in your key so the application can choose the right result.

MORE WAYS TO BUILD

The same API.
More possibilities.

Prompt versions

Store prompt text and model settings under an explicit version ID. Your application selects the version to load for each request.

support-agent:v3
Recommendations

Save product or content recommendations computed by your pipeline. Fetch a prepared list by user or segment ID while background jobs refresh it.

recommendations:user-42
Feature serving

Keep pipeline-computed ML features under an entity-and-version key. Your application retrieves the prepared values when serving a prediction.

product-42:features-v2
User feedback

Record ratings, comments, and the response or model version they refer to. Use SQL to inspect the published feedback and compare results.

response-108:feedback-1
WHY ROCKBEE

Your AI stack.
A shared data foundation.

Flexible records. Keep model-specific fields in JSON.

Durable object storage. Keep saved data independent of model workers.

Independent readers. Grow serving compute as more applications use the results.

Your application runs the models and selects the context. Rockbee stores and serves the data.GET follows reader catch-up. SQL follows publication.

05 / THE CONTRACT

Simple to use.
Clear about behavior.

Durable writes.
A successful mutation means SlateDB acknowledged durability. The client exposes uncertain outcomes and never automatically replays uncertain writes.
Eventual reads.
GET follows reader catch-up. SQL follows Parquet publication. A successful write can take time to appear on either read path.
Bounded SQL.
Reader query memory, concurrency, and timeouts are configurable. Results have explicit row and byte limits.

06 / BUILD SOMETHING

Take the small API
for a real spin.

Run a writer, a reader, and a gateway locally. Try byte lookups, write your first JSON document, then query the published table.

Open the setup guide

Rust via rustup + Docker Desktop.
See the guide for native DuckDB build setup on macOS.

TERMINAL / FRESH LOCAL SETUP
git clone https://github.com/umit/rockbee.git
cd rockbee

# Requires Docker and port 4566 available.
docker compose up -d --wait
make local

The runner prints service addresses and uses a unique storage prefix. Keep it open; use its gateway address in your client.

Already running LocalStack? Follow the setup guide ↗

A FEW GOOD QUESTIONS

Before you build.

Is this a key-value store or a SQL database?

The core stores opaque byte keys and values. JSON tables add document IDs and real DuckDB SELECT queries over a derived Parquet projection. SQL reads JSON tables; it does not interpret arbitrary byte values.

What does scaling mean here?

Reader processes share durable storage and can be provisioned separately from the writer. There is one writer per prefix. Operators configure readers; automatic scaling, sharding, and automatic writer failover are outside the current scope. Capacity depends on the workload, caches, gateway, network, and object store.

Why object storage?

Durable data lives independently of serving processes. Readers fetch shared files and cache their working sets locally, so each reader does not need a full independent durable replica. Cold reads, object requests, transfer costs, and cache warmup remain part of the design.

What should I evaluate first?

Start with a product catalog, application content, or saved model outputs where eventual reads fit the workflow. Run a writer and reader against your object store, then measure lookup latency, SQL publication lag, and recovery with your own data. The setup guide walks through the full path.

Small surface.
Room to build.

Explore Rockbee on GitHub