RovaDB

Overview

RovaDB is a Go-first embedded relational database engine built for clarity, portability, and long-term extensibility. It is intended to feel natural to Go developers, stay understandable to contributors, and grow without boxing itself into a dead-end architecture.

Supported Features

• CREATE TABLE
• INSERT INTO ... VALUES
• SELECT over a single table with projection, WHERE, ORDER BY, and COUNT(*)
• UPDATE
• DELETE
• ALTER TABLE ... ADD COLUMN
• Positional args via ? in Exec, Query, and QueryRow
• Strict value support for INT, TEXT, BOOL, REAL, and NULL

Supported SQL

Schema Types

INT, TEXT, BOOL, and REAL.

Positional Arguments

The public API supports one-shot positional argument binding on Exec(query string, args ...any), Query(query string, args ...any), and QueryRow(query string, args ...any). Use ? placeholders only. Binding is positional, left-to-right, and the argument count must match exactly.

Canonical Example

db, err := rovadb.Open("app.db")
if err != nil {
    log.Fatal(err)
}
defer db.Close()

if _, err := db.Exec("CREATE TABLE users (id INT, name TEXT, active BOOL)"); err != nil {
    log.Fatal(err)
}

if _, err := db.Exec("INSERT INTO users VALUES (?, ?, ?)", 1, "Alice", true); err != nil {
    log.Fatal(err)
}

rows, err := db.Query("SELECT id, name FROM users WHERE active = ? ORDER BY id", true)
if err != nil {
    log.Fatal(err)
}
defer rows.Close()

The repository includes a fuller example that covers open, write, close, reopen, and query flow.

Why RovaDB Exists

RovaDB exists to provide a pure Go embedded relational database with practical SQL support. It is not trying to outcompete mature databases on breadth or raw performance. The goal is to offer a practical embedded SQL engine for Go that is straightforward to understand, realistic to adopt, and structured to grow carefully over time.

Project Goals

• Feel natural to Go developers
• Embed cleanly into Go applications
• Provide a focused SQL feature set first
• Keep the codebase understandable
• Separate major engine layers cleanly
• Allow future growth toward a broader SQL engine

Architectural Direction

RovaDB grows around these major layers:

• parser
• binder / catalog
• planner
• executor
• storage
• transaction / pager
• SQL function and operator registry

The intended execution path is:

SQL -> AST -> Bound AST -> Logical Plan -> Physical Plan -> Executor

Even in a deliberately small engine, those boundaries matter. They reduce coupling and make it possible to add features later without tearing the engine apart.

Audience