HolaDB

A different way
to think about
databases.

HolaDB is an independent database system built from the ground up in Rust, exploring new approaches to structured data storage and retrieval.

SQL, transactions, durable storage and PostgreSQL-compatible connectivity, on an engine that treats the structure in your data as something worth using.

Explore the architecture Development status

Stored data has structure. HolaDB asks what a database can do with it.

Tables are full of regularity: keys that count up, timestamps that advance, statuses that repeat, values that rarely change.

HolaDB is an investigation into making that regularity part of the storage engine itself. Once a stretch of data is sealed, the engine may keep it in a compact representation it derives from the data. It keeps that representation only after checking it against the original, and conventional storage is always there as the fallback.

None of this reaches the surface. You write SQL, open transactions and connect with the drivers you already use. How a segment is represented is an internal decision that never shows up in a query result, the wire protocol or a backup.

For the application
Tables, SQL and transactions. A PostgreSQL-compatible endpoint, and SDKs for TypeScript, Python and Rust.
For the engine
An append-only log, immutable segments and content hashes, written in Rust with no unsafe code.
For the project
A question about storage, pursued with tests and measurement instead of claims.

From a connection
to the disk.

A query passes through seven layers on its way to storage. Each one is a separate Rust crate with its own tests, and each is kept ignorant of what it has no reason to know.

  1. Clients

    • psql and PostgreSQL drivers
    • TypeScript, Python and Rust SDKs
    • CLI and Studio

    An application connects with a PostgreSQL driver it already has, or with an SDK that speaks HolaDB's native protocol directly.

  2. Protocol

    • PostgreSQL wire protocol v3
    • Native binary protocol

    Two endpoints, one session layer behind them. The native protocol uses length-prefixed binary frames with request ids.

  3. Server

    • Authentication
    • Authorization
    • TLS
    • Metrics, logs, audit

    One process per database directory and a thread per connection. Every request is authenticated and checked against the user's privileges before it runs.

  4. SQL

    • Parser
    • Binder
    • Planner

    A deterministic pipeline for a defined subset of SQL. Syntax outside the subset is refused by name, never guessed.

  5. Session

    • Transactions
    • Cursors

    A statement sees the latest committed state and its own transaction's writes. At commit, every row the transaction wrote must be unchanged since it first touched it.

  6. Store

    • Catalog
    • Secondary indexes
    • Write sets
    • Commit journal

    Maps SQL rows to engine records, maintains indexes, and journals commits that span tables so a crash leaves all of a transaction or none of it.

  7. Engine

    • Write-ahead log
    • Sealed segments
    • Record index
    • Recovery
    • Representation controller

    Knows nothing about SQL. It appends and syncs, seals the log into hashed segments, decides how each segment is represented, and replays the log on the next open after a crash.

  • The engine is independent of SQL, the catalog and the protocol.
  • SQL is independent of how data is stored.
  • The backup format is independent of the network protocol.

What is built, and tested, today.

SQL and transactions

Tables, indexes, inserts, updates, deletes, filtered and ordered selects, whole-table aggregates and EXPLAIN. Transactions are atomic across tables and durable once acknowledged. Isolation is read committed with optimistic write validation: the first committer wins, the other retries.

The subset is deliberate. Joins, subqueries and GROUP BY are not implemented, and a statement that uses them is refused with an error that names the construct. 

BEGIN;
UPDATE accounts SET balance = balance - 10
  WHERE id = 1;
UPDATE accounts SET balance = balance + 10
  WHERE id = 2;
COMMIT;

PostgreSQL-compatible connectivity

A PostgreSQL wire-protocol endpoint accepts psql, libpq and the drivers built on it, with the simple and extended query protocols and SCRAM-SHA-256 authentication. The SQL they send is HolaDB's subset.

It is a protocol, not a PostgreSQL clone: there is no pg_catalog, COPY or LISTEN, so schema introspection from ORMs does not work yet. 

psql postgresql://app@127.0.0.1:5433/holadb

A TypeScript SDK with no dependencies

The SDK speaks the native protocol directly from Node 20 or later: queries with parameters, table helpers, transactions that commit on resolve and roll back on throw, paged cursors, and TLS. Python and Rust clients follow the same protocol. 

import { HolaDB } from "@holadb/client";

const db = await HolaDB.connect(
  "holadb://app:secret@127.0.0.1:7433",
);
const rows = await db.query(
  "SELECT * FROM users WHERE id = $1", [1],
);

await db.transaction(async (tx) => {
  await tx.execute(
    "DELETE FROM users WHERE id = $1", [2],
  );
});
Durability and recovery
A commit returns after the write-ahead log is synced. After a crash there is nothing to run: the next open replays the log, discards a torn tail and rolls back transactions that never reached their commit marker.
Backup and restore
Offline backups, online snapshots from a running server, and incremental backups that reuse unchanged files. Every file is hashed with SHA-256, and log archiving allows a restore to an earlier commit.
Authentication and TLS
Users, roles and per-table privileges, checked on every request. Passwords never cross the wire: both protocols use SCRAM-SHA-256, with channel binding over TLS.
Tools around the server
A command-line client, Studio (a local web interface for browsing tables and running SQL), a metrics and health endpoint, a container image, and importers for PostgreSQL, MySQL and MongoDB data.

Find out,
then say so.

  • Refuse, never approximate.

    Anything outside the supported SQL is rejected with an error that names it. Nothing is silently ignored or guessed.

  • Verify before trusting.

    Sealed segments are checked against their content hashes before any data is returned. An index that cannot be verified is rebuilt from the log.

  • Efficiency has to prove itself.

    A compact representation is kept only when it reproduces the original data exactly. Otherwise the segment stays in conventional form.

  • Durable means synced.

    A write that fails is never acknowledged and never reappears. When an outcome cannot be known, the server says so instead of picking one.

  • Crashes are an ordinary input.

    Recovery runs on every open. Multi-table commits are journaled so that an interruption at any point leaves all of a transaction or none.

  • Measure, then write it down.

    Behaviour is tested under sustained load and the limits found are recorded beside the results. Unsafe Rust is forbidden in every crate.

Currently in development

HolaDB is undergoing extended reliability, endurance and recovery testing as we prepare for its first public beta.

It is not ready for production workloads, and no release date has been set. This page will change when the project does.

Implemented and tested

  • SQL subset, transactions and secondary indexes
  • Native protocol and PostgreSQL wire protocol
  • Crash recovery, backups and point-in-time restore
  • Authentication, roles and TLS
  • TypeScript, Python and Rust clients
  • Linux on x86-64 and arm64

Not there yet

  • Joins, subqueries and GROUP BY
  • Snapshot isolation; reads are read committed
  • Concurrent writers; one writer at a time
  • Windows support and packaged macOS builds
  • Signed release artifacts
  • A public source repository and downloads