DataVec — How it works

Infrastructure Pipeline

The Compiled Deployment Pipeline

Explore the pipeline phases to inspect how standard JavaScript code is compiled, linked, and hosted on the machine your app runs on.

PHASE 01

BUILD

Write standard JavaScript

Build endpoints using Next.js static layouts, Web Workers, or WebSockets, connecting securely to Postgres databases inside secure isolated sandboxes.

PHASE 02

TRANSLATE

Compile directly to C

The DataVec Builder translates your JavaScript and WebSocket logic into idiomatic native C. The Builder is taught by worked examples rather than told a set of rules — which is what makes the output read like C somebody wrote, not C somebody generated.

PHASE 03

RUN

Native Runtime Engine

Serve requests on a standalone process or dedicated VMs with native SSL handshakes, S3 object storage, and DB drivers.

PHASE 04

METER

Billed by the machine

You pay for the VM-time your app actually uses — cost-plus, the way you pay for a server. No per-request, per-duration, or bandwidth metering, and no markup on synthetic units.

Architectural Schematics

Visualizing compiler & runtime efficiency

DataVec replaces the virtualization stack — VM, language engine, garbage collector — with an M:N virtual kernel: a userland kernel, written in C, that isolates and memory-protects each connection in-process, with no language VM and no WebAssembly. Hover over the symbol map and stack diagrams below to inspect the design.

The Compiler

Taught, not specified.

In 1725 Johann Fux taught counterpoint by species — one new constraint at a time, worked out on the page rather than stated as law. Bach, Haydn, Mozart and Beethoven all learned from it.

We build our compiler the same way. Every build carries a curriculum: JavaScript beside the exact C it becomes, graded from the simplest shape up through the hard ones. Idiomatic C is a craft rather than a specification — you can write rules for it indefinitely and still not pin it down; show the work and it transfers. That is what produces mappings like these, and why nothing interprets your code at runtime:

JavaScript Source

Compiled C Target

req.headers.get(...)

env.DB.query

Response.json(data)

get_header(...)

db_query(...)

create_response(...)

→ Hover over any JavaScript or C node above to inspect compiled symbols.

Verified, not asserted. Three reference workers — static routing, environment-bound handlers, and JWT auth — replay identical requests against the real hono 4.12.27 and against our compiled C. We diff the responses. They agree, down to the WWW-Authenticate header on a rejected token.

The Runtime

Virtualization Layer Comparison

Standard serverless stacks execution layers — a VM, a JIT engine, a garbage collector — each adding latency and cache pressure. DataVec compiles your service into a standalone virtual kernel daemon that aligns data layout with code layout, so it cache-misses far less and does more with the same machine — the same rented droplet you would spin up yourself. The advantage is the software, not the silicon, which is why you can reproduce it on your own hardware. Memory is reclaimed on an allocator whose allocation and release are both bounded-time operations, so the flat latency tail is a property we hold rather than a pause we avoid.

DataVec compiled C

Deductive Socket Poller

Stackless Coroutine

Isolated Micro-Heap SQLite

Single self-contained binary
No per-invocation cold starts

Virtualized V8 Isolate

API Gateway (metered)

Firecracker VM (startup)

V8 Isolate engine

Node.js Runtime & GC

Dynamic JS Route (V8 Heap)

Multi-layer runtime stack
Cold start on scale-up

Every protocol, written here. HTTP/1.1, HTTP/2 with its own HPACK, WebSocket, the PostgreSQL wire protocol on both sides, SMTP, IMAP4rev2, S3 and ACME — around twenty thousand lines of wire protocol, all of it ours. No nghttp2, no libpq, no embedded HTTP server. Your database query is a function call in one address space, not a socket round trip through two libraries. It links as a single binary, optimised whole-program, so the compiler inlines across what used to be process boundaries.

State

State on three dials

Every service chooses where its state lives, what it survives, and how long it lives — three independent dials, every combination backed by SQLite and enforced at dispatch. Distribution is a choice you make, priced in the machines you allocate, never an ambient platform behavior.

DURABILITY

A COMMITTED WRITE SURVIVES

HOW

memory / box-coherent

worker restarts, at memory speed

shared mappings — the tier a garbage-collected runtime structurally cannot offer

fsync

power loss on the machine

SQLite WAL, synced on commit

off-box, streaming

losing the machine — continuous off-site recovery

the write-ahead log streams to object storage behind the commit path, at no cost to it

off-box, synchronous

losing the machine, with no loss at all

every commit is acknowledged by a quorum of your own log nodes before it returns — fenced by one monotonic lease, so a demoted writer is refused everywhere at once

Locality sets the scope — a connection, a machine, your service's fenced primary. Lifetime binds state to a login session or a single token, verified cryptographically and expiring with its principal. The dials compose: session-scoped state on a service-wide store with synchronous off-box durability is one line of configuration.