Native engine and benchmarks

The default engine is celld 0.6.2. The native engine is in progress: sobjects dev --engine native runs a Wrangler project's Worker and Durable Objects inside the Node process, with no celld. Each object's storage is its own SQLite file (node:sqlite) under --persist-to, which defaults to <project>/.sobjects/native.

sobjects dev ./my-worker --engine native --port 8787

The native engine is for trusted code. There's no isolate between the app and the engine, and objects get full Node APIs. Use celld for apps you don't control. It needs Node.js 22.16 or newer.

The app's own code is bundled with esbuild, which handles TypeScript and define. npm packages load from node_modules as in any Node program, so packages with native addons (for example better-sqlite3) work. cloudflare:workers and cloudflare:email resolve to the engine's shims.

#What works

#Check portability

sobjects build ./my-worker --strict

build lists each Node.js built-in the app imports, and whether Cloudflare supports it, stubs it, or needs a nodejs_compat flag or compatibility date. It also flags packages with compiled native addons. A portable app runs on Cloudflare, celld and the native engine. A native-only app runs only here. --strict exits 1 for native-only apps.

#Bucket backups

export AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY=...
export S3_ENDPOINT=https://<account>.r2.cloudflarestorage.com   # omit for AWS S3; set AWS_REGION there
sobjects dev ./my-worker --engine native --backup-bucket s3://my-bucket/node-a

With --backup-bucket, the engine copies each object's SQLite file to <prefix>/native/<script>/<class>/<id>.sqlite within --backup-interval-seconds (default 10) of a change, and again when the object closes or the engine stops. On start, objects in the bucket that have no local file are downloaded and their pending alarms scheduled. Tested against Cloudflare R2 and SeaweedFS.

Limits of interval mode:

• The local file is the source of truth. If the disk is lost, writes since the last upload are lost too.
• Each upload sends the whole file.
• One node per prefix. A node that finds a copy another node wrote stops backing that object up and logs it.
• There is no point-in-time restore in this mode; enable bucket versioning if you need history.

#Durable mode

sobjects dev ./my-worker --engine native --backup-bucket s3://my-bucket/node-a --backup-mode durable

In durable mode, nothing the engine acknowledges is lost if the disk is:

Limits:

• A write costs one batched bucket round trip: a few ms to a local MinIO, typically 10 to 40 ms to S3 or R2 in the same region.
• Fetches and WebSocket messages an object sends while its writes are pending aren't held back.
• Writes from timers or waitUntil outside an event ship within 200 ms, with no gate.
• A node in durable mode doesn't start until it can reach its bucket.
• The store needs conditional writes (If-None-Match). AWS S3, Cloudflare R2, SeaweedFS and MinIO from RELEASE.2025-09-07 support them. Backblaze B2, Garage and DigitalOcean Spaces don't. The node checks this at start.

#Point-in-time recovery

const bookmark = await this.ctx.storage.getBookmarkForTime(Date.now() - 60 * 60 * 1000);
const undo = await this.ctx.storage.onNextSessionRestoreBookmark(bookmark);
this.ctx.abort(); // the next request sees the object as it was an hour ago

getCurrentBookmark() and getBookmarkForTime(time) return bookmarks. onNextSessionRestoreBookmark(bookmark) restores on the object's next start and returns a bookmark that undoes the restore. A bookmark the bucket can no longer rebuild, or a time before the kept history, is refused with a RangeError. Without durable mode, these methods throw.

#Worker threads

sobjects dev ./my-worker --engine native --threads 4

Each Durable Object lives on exactly one thread, chosen from its ID. A thread that doesn't answer for --thread-stall-seconds (default 30), throws an uncaught error, or exceeds --thread-memory-mb is replaced, and its objects reload from their SQLite files.

• Threads are not a security boundary.
• A call that crosses threads costs roughly 0.3 to 0.5 ms more.
• In one test, 16 CPU-bound objects went from 89 req/s on one thread to 169 req/s on 4 and 182 on 8 (M1 Pro).

#Several nodes

# on each node, with a unique, stable name and the same secret
export SOBJECTS_CLUSTER_SECRET=...   # 32+ characters, identical on every node
sobjects dev ./my-worker --engine native --backup-bucket s3://my-bucket/app --backup-mode durable \
  --node-name node-a --peer-listen 10.0.0.5:9790

With --node-name, nodes in durable mode share one bucket prefix and each object runs on one node at a time.

Not yet: forwarding without --peer-listen, TLS between nodes, --node-name combined with --threads, and cross-node compaction.

#Running as a service

sobjects up runs the native engine when sobjects.toml has a [native] table in place of [celld]:

[native]
project = "./my-worker"          # the Wrangler project to run; relative to this file
listen = "127.0.0.1:8787"        # default
# data_dir = "/var/lib/serverless-objects/native"  # default: $SOBJECTS_DATA_DIR/native
# idle_evict_seconds = 60
# drain_seconds = 30
# threads = 2

[native.backup]
bucket = "s3://my-bucket/app"
mode = "durable"                 # default here; "interval" is the other choice
# retention_days = 7
# endpoint = "https://<account>.r2.cloudflarestorage.com"
# region = "auto"

# [native.cluster]
# node_name = "node-a"
# lease_seconds = 10
# peer_listen = "10.0.0.5:9790"
# peer_advertise = "http://10.0.0.5:9790"

Credentials and SOBJECTS_CLUSTER_SECRET come from the environment, never the file. For a systemd unit, put them in sobjects.env beside the config.

• --detach, status, logs and down work as with celld. down waits up to a minute for the engine to upload what's left.
• sobjects service install writes a unit that restarts the node if it exits, including after it loses its lease.
• [ingress] routes to [native].listen by default.
• [admin] and the dashboard aren't available with [native] yet. sobjects deploy is for celld: restart the node to run new code.

Without [native.backup], objects exist only in data_dir. The full key list is in the CLI reference.

#Benchmarks

packages/conformance/bench-app is one Worker with one Durable Object class. The same code runs on Cloudflare, Wrangler, celld and the native engine.

npm run bench --workspace=sobjects-conformance -- --target native     # or celld, wrangler
npm run bench --workspace=sobjects-conformance -- --url https://sobjects-bench.<you>.workers.dev

#Durability differs by target

Writes are not equally durable across targets, and that dominates the write rows:

#Results, 20 Oct 2026

Client: Apple M1 Pro, Node.js 24.12. Local targets on loopback: serverless-objects 0.5.0 native engine, celld 0.6.2 (celld dev), Wrangler 4.150.0. Cloudflare: the same app on a workers.dev subdomain on the free plan, served from Frankfurt, about 130 to 200 ms from the client. One run each; treat differences under about 20% as noise.

Inside the Worker, mean per call (500 sequential calls to one object, 100 for SQL):

From the client:

* Limited by the client: 32 requests in flight over a roughly 200 ms round trip caps out near 160 req/s. These rows say nothing about Cloudflare's capacity.

Native engine in durable mode, against a local MinIO, 32 requests in flight spread over N objects:

#Reading the results

• On one machine, the native engine and celld have no network hop to the object, which is where most of their advantage over Cloudflare comes from. It is the trade-off of running on one node, not a faster implementation of the same guarantees.
• celld's single-node write throughput falls as more objects write at once (from about 1,800 to 240 writes/s under celld serve with SeaweedFS).
• The native engine in its default mode is the fastest target and its writes are the least durable. Choose it when the app is trusted and a few seconds of writes on one machine are an acceptable loss. Choose Cloudflare or celld when every acknowledged write must survive the machine. Durable mode closes this gap for the native engine at the cost shown in its table.

Full tables and methodology: benchmarks source and native engine source.