HyperDB

Why HyperDB

HyperDB brings the developer experience of a backend like Convex to a database that can run in the browser and on the server. You describe your data with typed schemas, read it through reactive selectors, and change it through transactional actions. The same slice of schema, selectors, and actions can be shared by the client and backend; only the storage driver differs. Why HyperDB? gives the technical background.

Top Features

Typed schemas

Define tables and validators with defineTable and v. Rows, queries, and index columns are fully type-checked end to end.

Indexed queries

Query through B-tree and hash indexes with a fluent, type-safe builder. Every table index is a B-tree, so sorted inserts and range scans stay O(log n). This fits local-first fractional ordering, where reordering an item touches a single token instead of rebuilding the list.

Reactive by default

Selectors are cached and subscribed. They re-run only when a mutation touches a range they actually scanned.

Runs everywhere

The same schema, selectors, and actions run in the browser (in-memory, IndexedDB, WebAssembly SQLite) and on the server (native SQLite). On the backend the runtime reads only the rows a selector touches instead of hydrating the whole dataset into memory.

JavaScript selectors and actions

Write selectors and actions as ordinary JS (loops, conditionals, function calls) on both client and server. HyperDB gives you fast indexed lookups underneath, not a query language to learn.

Plain immutable data

Components get plain, frozen rows, with no proxies and no observer() wrapper, so it composes with React’s rendering model directly.

React & devtools

First-class React hooks plus an in-app devtool that traces every selector and mutation into a call tree.

Start here

Introduction What HyperDB is and when to reach for it.

Why HyperDB? Why HyperDB is built.

How HyperDB Works The three layers: tables, commands, and the DB runtime.

Quickstart Define a table, run a query, and wire it into React.