Zova

SQLite-backed embedded database for records, objects, vectors, and graph-aware relationships in local .zova files.

Zova keeps SQLite as the relational core and adds native storage for content-addressed objects, chunk manifests, streaming writes, exact vector search, SQL-native vector queries, graph relationships, SQL-native graph traversal, transaction-aware app events, bound object/vector stores, diagnostics, salvage, backup, compact copy, restore, and a trusted extension host foundation.

Current package version: 0.21.0.

Zova is pre-1.0. The current .zova file format_version is 5. Zova 0.21.0 is the extension host release: trusted extension lifecycle, explicit local dynamic loading, and bundled target-aware trgm fuzzy lookup.

Contents

1. Install
2. Dependency Matrix
3. Quick Start
4. What Zova Stores
5. Architecture
6. Records
7. Convert SQLite To Zova
8. Objects
9. Vectors
10. SQL-Native Vector Search
11. Graphs
12. SQL-Native Graph Traversal
13. Operational Safety
14. App Events
15. Extensions
16. Diagnostics And Salvage
17. CLI
18. Bindings
19. Build From Source
20. SQLite Policy
21. Current Boundaries
22. Testing
23. Release Package Policy
24. License

Install

Rust:

cargo add zova

or:

[dependencies]
zova = "0.21.0"

Python:

uv add zova

or:

python -m pip install zova

Go:

go get github.com/atasesli/zova/bindings/go@v0.21.0

The Go binding uses cgo over Zova's C ABI. Build or provide the C ABI library before using it from another project.

C ABI:

zig build c-abi

CLI:

zig build
zig-out/bin/zova --help

Dependency Matrix

Zova vendors SQLite. You do not need a system SQLite installation.

Path	Main Command	Needs Zig	Needs Rust	Needs C Compiler	Notes
Rust	cargo add zova	yes	yes	yes	zova-sys builds Zova's native C ABI from bundled source
Python	uv add zova / pip install zova	yes	yes	yes	source-first PyO3 build; no wheel matrix yet
Go	go get github.com/atasesli/zova/bindings/go@v0.21.0	yes, for C ABI build	no	yes, cgo	caller provides zova.h and libzova_c.a
C ABI	zig build c-abi	yes	no	yes	produces static libzova_c.a
Zig	package source	yes	no	yes	native API
CLI	zig build	yes	no	yes	source-built command line tool

Minimum tool versions used by the project:

Tool	Minimum / Current
Zig	0.16.0 or newer
Rust	1.79 or newer
Go	1.22 or newer
Python	3.10 or newer
SQLite	vendored 3.53.2

Quick Start

Rust

use zova::{Database, Step};

fn main() -> Result<(), zova::Error> {
    let mut db = Database::create("app.zova")?;
    db.exec("create table notes(id integer primary key, body text not null)")?;

    let mut insert = db.prepare("insert into notes(body) values (?1)")?;
    insert.bind_text(1, "hello from Rust")?;
    assert_eq!(insert.step()?, Step::Done);

    let object_id = db.put_object(b"large bytes live here")?;

    db.create_vector_collection(
        "chunks",
        zova::VectorCollectionOptions {
            dimensions: 2,
            metric: zova::VectorMetric::L2,
        },
    )?;
    db.put_vector("chunks", "chunk:1", &[0.0, 1.0])?;

    println!("stored object: {object_id:?}");
    Ok(())
}

Python

import zova

with zova.Database.create("app.zova") as db:
    db.exec("create table notes(id integer primary key, body text not null)")

    with db.prepare("insert into notes(body) values (?1)") as stmt:
        stmt.bind_text(1, "hello from Python")
        assert stmt.step() == zova.Step.DONE

    object_id = db.put_object(b"large bytes live here")

    db.create_vector_collection(
        "chunks",
        zova.VectorCollectionOptions(2, zova.VectorMetric.L2),
    )
    db.put_vector("chunks", "chunk:1", [0.0, 1.0])

Go

package main

import zova "github.com/atasesli/zova/bindings/go"

func main() {
    db, err := zova.Create("app.zova")
    if err != nil {
        panic(err)
    }
    defer db.Close()

    if err := db.Exec("create table notes(id integer primary key, body text not null)"); err != nil {
        panic(err)
    }
}

What Zova Stores

Zova has four first-class storage shapes:

• Records: normal SQLite tables, indexes, views, triggers, and SQL.
• Objects: content-addressed bytes, chunked with FastCDC-v1 and addressed by SHA-256(full bytes).
• Vectors: named vector collections with exact flat search and SQL-native query helpers.
• Graphs: named relationship graphs with application-provided stable node IDs and explicit directed edges.

Applications own their metadata in normal SQL tables. Zova-owned private tables store object bytes, manifests, chunk rows, vector collections, and vector rows. User tables should reference Zova object ids or vector ids.

SQL row
  title       = "receipt.pdf"
  object_id   = <32-byte ObjectId>
  vector_id   = "receipt:chunk:42"

Architecture

flowchart TD
    App["Application"]
    API["Zova API<br/>Rust, Python, Go, Zig, or C ABI"]
    CLI["zova CLI<br/>inspect, check, doctor, salvage, backup"]
    File["local .zova file<br/>SQLite database"]
    UserSQL["User SQL tables<br/>records and metadata"]
    Meta["_zova_meta<br/>identity and format"]
    Objects["_zova_objects<br/>object ids and sizes"]
    Chunks["_zova_chunks<br/>verified chunk BLOBs"]
    Manifest["_zova_object_chunks<br/>object manifests"]
    VecCols["_zova_vector_collections<br/>dimensions and metric"]
    Vecs["_zova_vectors<br/>f32 vector BLOBs"]
    Graphs["_zova_graphs<br/>named relationship graphs"]
    Nodes["_zova_graph_nodes<br/>stable app node ids"]
    Edges["_zova_graph_edges<br/>directed relationships"]
    Ext["_zova_extensions<br/>installed extension registry"]
    ExtStore["_zova_ext_name_*<br/>extension-owned storage"]

    App --> API
    App --> UserSQL
    API --> File
    CLI --> File
    File --> UserSQL
    File --> Meta
    File --> Objects
    File --> Chunks
    File --> Manifest
    File --> VecCols
    File --> Vecs
    File --> Graphs
    File --> Ext
    Ext --> ExtStore
    Graphs --> Nodes
    Nodes --> Edges
    Objects --> Manifest
    Manifest --> Chunks
    VecCols --> Vecs

Loading

The file boundary is explicit:

*.zova  -> Zova database
other   -> normal SQLite database

Renaming app.db to app.zova is not enough. A valid Zova database has Zova metadata and private schema.

Records

Records are just SQLite.

Use normal SQL for application tables:

create table attachments(
  id integer primary key,
  filename text not null,
  object_id blob not null,
  vector_id text
);

The C ABI and all bindings expose prepared statements, bind/step/column access, transactions, savepoints, last_insert_rowid, changes, total_changes, and column names. Serious application metadata belongs here.

Convert SQLite To Zova

Existing SQLite databases can be copied into a new .zova file without mutating the source database.

Use this when an application already has normal SQLite tables and wants to add Zova objects, vectors, diagnostics, backup, compact copy, and salvage around the same local file model.

Conversion is exposed through the native APIs:

try zova.convertSqliteToZova("app.sqlite", "app.zova");

zova::Database::convert_sqlite_to_zova("app.sqlite", "app.zova")?;

err := zova.ConvertSqliteToZova("app.sqlite", "app.zova")

zova.convert_sqlite_to_zova("app.sqlite", "app.zova")

The destination must be a new .zova path. If the SQLite source uses table names reserved by Zova, conversion fails instead of silently rewriting the application schema.

For a full application migration path, see SQLite App To Zova App Migration Guide.

Objects

Objects are raw bytes stored by content identity:

ObjectId = SHA-256(full object bytes)

Zova splits objects into FastCDC-v1 chunks and deduplicates chunks inside the same .zova file. You can put/get whole objects, range-read object bytes, inspect manifests, fetch verified chunks, store loose chunks, and assemble a complete object from chunks.

Optional Bound Object And Vector Stores

Single-file .zova remains the default. In v0.21.0, applications can opt into one bound object store and one bound vector store when large object bytes or vector rows should live beside the main records database:

zova object-store create objects.zova
zova object-store bind main.zova objects.zova
zova object-store info main.zova

zova vector-store create vectors.zova
zova vector-store bind main.zova vectors.zova
zova vector-store info main.zova

Use bind for new or empty Zova-owned storage. If the main file already has object rows or vector rows that you want to move out, use split instead:

zova split --objects main.zova objects.zova
zova split --vectors main.zova vectors.zova

split is an in-place local migration. It creates a new store file, copies the selected Zova-owned private rows into that store, clears those private rows from the main file, binds the new store, and verifies the result. User SQL tables and rows stay in main.zova. The destination store must be a new .zova path; Zova does not overwrite existing files. Take a backup before splitting; after a successful split, rollback means restoring that backup or running another explicit local migration.

After binding, Zova attaches the object store to the main SQLite connection and routes _zova_objects, _zova_chunks, and manifests through the internal object_store schema. A bound vector store similarly routes vector collections and vector rows through the internal vector_store schema. User SQL records stay in the main database. If a store file is moved, run bind again with the new path:

zova object-store bind main.zova new/path/objects.zova
zova vector-store bind main.zova new/path/vectors.zova

bind is a safe set-or-replace operation for already-empty or already-bound storage: Zova validates the new store file before updating the main database's binding metadata. It rejects a first-time bind when the main file already contains object/vector rows, because that would hide existing data. Use split for that case. The main database records store identity, a bound-set id, and object/vector epochs. Normal open rejects missing stores, wrong stores, marker mismatches, and split bound sets instead of silently continuing. doctor and check --deep report those as bound_store diagnostics so the problem is visible without mutating any file. For a moved store path, run bind again with the new location; marker mismatches are treated as consistency problems, not path-repair prompts.

backup, compact, and restore are bound-store-aware: they copy readable bound object/vector data back into the new destination so the produced file is self-contained.

Object writes, deletes, chunk writes, assembly, and ObjectWriter.finish can participate in the same Zova transaction/savepoint as main-file SQL when an object store is bound. Vector collection and vector row mutations follow the same transaction/savepoint stack when a vector store is bound. Binding management is still explicit: bind, unbind, and replacement binds are rejected while the main database has an active transaction or savepoint.

SQLite's ATTACH rules still matter. Multi-file transactions are crash-atomic only under SQLite's documented journal-mode conditions. Zova does not claim a stronger guarantee; the bound-set id and epoch exist so Zova can detect and explain split-file states during open, doctor, and check --deep.

This is local, manual storage placement. It is not distributed storage, cloud sync, automatic path repair, or a multi-file transaction guarantee. Zova supports one optional object store and one optional vector store; multiple named stores are deferred.

Use ObjectWriter when bytes arrive over time:

let mut writer = db.object_writer()?;
writer.write(b"chunk one")?;
writer.write(b"chunk two")?;
let object_id = writer.finish()?;

Deleting an object removes Zova-owned object rows and unreferenced chunks. It does not scan or mutate user SQL rows. SQLite may reuse freed pages without shrinking the file; use explicit vacuum or compact copy when you want file-size reclamation.

Vectors

Vectors live in named collections:

collection: "chunks"
dimensions: 384
metric: cosine | l2 | dot
vector id: application-provided text

Supported metrics:

• cosine distance: 1 - cosine_similarity
• L2 distance: Euclidean distance
• dot distance: -dot_product

Zova supports collection create/info/list/delete, vector CRUD, batch upsert, exact search, candidate-filtered search, search-by-id, and inclusive distance thresholds.

Search is exact and flat-scan in 0.21.0. It is good for local datasets, offline ranking, deterministic tests, and SQL-filter-first workflows. It is not yet an ANN engine for million-scale low-latency search.

SQL-Native Vector Search

Zova registers SQL vector helpers on zova.Database connections:

zova_vector_distance(collection, vector_id, query_vector_blob)
zova_vector_distance_by_id(collection, vector_id, source_vector_id)

It also exposes a read-only virtual table:

select
  c.id,
  c.text,
  s.distance
from zova_vector_search as s
join chunks as c on c.vector_id = s.vector_id
where s.collection = 'chunks'
  and s.query_vector = ?1
  and s.top_k = 10
order by s.rank;

query_vector_blob is little-endian f32 data. This lets applications combine SQL metadata filters with vector ranking without pulling the whole metadata set into application code.

Graphs

Graphs let applications store relationships between records, objects, chunks, vectors, entities, facts, concepts, and external references.

Zova does not invent row IDs for your app. Nodes use stable IDs that the application provides:

message:123 --has_attachment--> object:8f...
message:123 --embedded_as--> vector:chunks:message-123
entity:person:alice --mentioned_in--> message:123
fact:991 --supported_by--> chunk:doc7:12

Graph rows store topology and small routing fields only. Application metadata stays in normal SQL tables. Zova validates graph names, node IDs, edge types, edge endpoint existence, and Zova-owned targets such as object IDs, chunk IDs, and vector IDs. It does not validate arbitrary user SQL row existence; apps own that contract.

CLI inspection is bounded and privacy-aware:

zova graphs app.zova
zova graph app.zova app
zova graph-node app.zova app message:123
zova graph-neighbors --limit 20 app.zova app message:123
zova graph-walk --max-depth 2 --limit 50 app.zova app message:123

This is a local graph-aware relationship layer, not Neo4j, Cypher, GQL, Gremlin, SPARQL, or automatic LLM extraction.

SQL-Native Graph Traversal

Zova registers read-only graph virtual tables on Zova SQLite connections:

select m.body, g.edge_type
from zova_graph_neighbors as g
join messages as m on m.graph_node_id = g.node_id
where g.graph_name = 'default'
  and g.source_node_id = 'message:123'
  and g.direction = 'outgoing'
  and g."limit" = 20
order by g.rank;

For bounded directed walks:

select node_id, depth, predecessor_node_id, edge_type
from zova_graph_walk
where graph_name = 'default'
  and start_node_id = 'message:123'
  and edge_type_filter = 'mentions'
  and max_depth = 2
  and "limit" = 50
order by rank;

zova_graph_neighbors returns one-hop neighboring nodes. zova_graph_walk returns the start node plus bounded reachable nodes. In both helpers, visible node_id is the returned node ID; input nodes use source_node_id or start_node_id. Apps join those node IDs back to their own SQL tables.

Operational Safety

Zova includes file-level safety operations:

zova backup app.zova app.backup.zova
zova compact app.zova app.compact.zova
zova restore app.backup.zova app.restored.zova

• backup uses SQLite's online backup API.
• compact uses SQLite VACUUM INTO to create a space-reclaiming copy.
• restore copies a backup into a new destination file.

Destinations must be new .zova paths. Zova does not overwrite destination files in these operations.

Savepoints are available for connection-local partial rollback:

SAVEPOINT name
ROLLBACK TO name
RELEASE name

Bindings also expose scoped savepoint helpers for cleanup ergonomics.

App Events

Zova has same-process listen / notify app events for storage workflows:

let mut listener = db.listen("message:1:attachments")?;
let object_id = db.put_object(b"attachment bytes")?;

db.begin_immediate()?;
// Store object_id in your SQL metadata row here.
db.notify("message:1:attachments", "changed")?;
assert!(listener.try_receive()?.is_none());
db.commit()?;

let event = listener.try_receive()?.unwrap();
assert_eq!(event.payload, "changed");

Notifications are explicit, local to one open database handle, in-memory, and non-persistent. They are delivered to subscription queues after commit. Rollback discards pending notifications. Savepoint rollback discards inner pending notifications; savepoint release preserves them for the outer scope. SQL zova_notify(...) participates in this model when transactions/savepoints are opened through Zova helpers; raw SQL transaction scopes that Zova cannot track are rejected instead of guessed.

This is useful when one process wants a clean storage-runtime boundary: a write workflow stores records, objects, vectors, or graph relationships, then notifies another part of the same process to reload by id. Graph mutations do not emit automatic events; call notify("graph:changed", "...") explicitly inside the same transaction when your app wants listeners to refresh graph-derived views. It is not cross-process delivery, replay, replication, audit logging, or automatic mutation tracking.

Queue details:

• channel names are ASCII, 1-128 bytes, using letters, digits, _, ., :, and -
• payloads are UTF-8 text, up to 64 KiB
• each subscription queue holds 1024 notifications
• when a queue overflows, Zova drops the oldest notification and reports the drop count on the next received notification
• v0.18 has polling only: use try_receive / drain loops, not callbacks

Extensions

Zova 0.21.0 includes the extension host plus the first bundled extension, trgm.

An extension is trusted process code plus private Zova metadata:

• the database records installed extension metadata in _zova_extensions
• an extension owns only tables with its _zova_ext_<name>_ prefix
• extension code is provided by the process, not loaded from the .zova file
• SQL functions or virtual tables are registered on each opened Zova connection
• install, check, and drop hooks run inside Zova-managed transactions
• extension registry and private storage live in the main database in v0.21

This keeps .zova files non-executable. A file may say it requires an extension, but the application or CLI process decides which extension code is available and trusted. Opening a database with an installed required extension whose code is unavailable fails clearly instead of silently ignoring the extension.

The host foundation supports app-registered extensions in native Zig and CLI inspection/management:

zova extension list app.zova
zova extension info app.zova <name>
zova extension check app.zova [name]
zova extension drop app.zova <name>
zova extension install app.zova <name>

It also supports explicitly trusted local .zovaext bundles for one process at a time:

zova extension trust ./my_ext.zovaext
zova --extension ./my_ext.zovaext extension install app.zova my_ext
zova --extension ./my_ext.zovaext check --deep app.zova
zova extension trusted
zova extension untrust my_ext

Trusted bundles are native code. Zova records hashes of the bundle manifest and library; if either changes, the bundle must be trusted again. Zova never loads extension code just because a .zova file contains extension metadata. If a command needs a dynamic extension that is missing or untrusted, diagnostics tell you to provide --extension <bundle.zovaext> or trust the bundle first.

install succeeds only for extensions registered in the current process or bundled with Zova. The default Zova process registry includes trgm, so this works in the normal CLI build:

zova extension install app.zova trgm

After installation, Zova registers the zova_trgm_* SQL surface on each open connection. trgm is for fuzzy target lookup: typo-tolerant matching over app document IDs that point back to records, objects, chunks, vectors, graph nodes, entities, facts, concepts, or external refs.

Those target refs may point at objects or vectors stored in optional bound stores. The extension index itself still stays in the main database.

select zova_trgm_create_index('messages');
select zova_trgm_put(
  'messages',
  'message:123',
  'record',
  'messages',
  '123',
  'attachment upload failed'
);

select document_id, score
from zova_trgm_search
where index_name = 'messages'
  and query = 'attachement failed'
  and threshold = 0.20
  and "limit" = 10
order by rank;

trgm is not SQLite FTS and not vector search. FTS is best for tokenized full-text search such as matching words and phrases. Vectors are best for semantic similarity. Trigram lookup is useful when the query or target has small spelling differences, filename variations, IDs, short labels, or operator-entered text where typo tolerance matters.

Extension operations do not emit automatic app events. If an application wants same-process listeners to react to indexing, it should call notify explicitly inside the same transaction, for example notify("search:indexed", "messages").

For the host contract, authoring shape, storage rules, diagnostics behavior, and current non-goals, see docs/extensions.md.

When moving a database that requires extensions, move or document the required extension code too. Bundled extensions such as trgm are available in the normal Zova process. Dynamic local extensions must be trusted and supplied again by the receiving CLI command or application process; .zova files never auto-load them.

Diagnostics And Salvage

Zova keeps diagnostics non-mutating by default:

zova check app.zova
zova check --deep app.zova
zova doctor app.zova
zova salvage --dry-run app.zova

doctor explains file health and suggests next actions. salvage --dry-run reports what appears recoverable. Real salvage writes readable, validated data into a new file:

zova salvage damaged.zova recovered.zova

Salvage never mutates the source file and never overwrites the destination. A good backup is still preferred when one exists. In v0.21, salvage is graph-aware: it copies valid graph topology and skips invalid graph nodes or edges, such as edges whose endpoint nodes or Zova-owned targets cannot be validated.

Diagnostics also include extension health. Unknown _zova_ext_* storage and corrupt trgm private tables are reported as extension issues without printing indexed text or private schema SQL.

Extension-aware salvage is hook-based. Core Zova never copies _zova_ext_* tables by guessing their meaning. If trusted extension code provides a salvage hook, Zova lets that extension copy, rebuild, or skip its own storage. If the extension code is unavailable or the extension has no salvage hook, extension storage is skipped and reported. The bundled trgm extension declares a no-op salvage hook in v0.21; real trgm index salvage/rebuild is deferred to v0.21.1.

CLI

The CLI is for inspection, diagnostics, and operational workflows:

zova info app.zova
zova stats --json app.zova
zova objects app.zova
zova object app.zova <object-id-hex>
zova chunks app.zova
zova chunk app.zova <chunk-id-hex>
zova vectors app.zova
zova vector-collection app.zova chunks
zova graphs app.zova
zova graph app.zova app
zova graph-node app.zova app message:123
zova graph-neighbors --limit 20 app.zova app message:123
zova graph-walk --max-depth 2 --limit 50 app.zova app message:123
zova tables app.zova
zova check --deep app.zova
zova doctor --json app.zova
zova object-store info app.zova
zova vector-store info app.zova
zova extension list app.zova
zova extension check app.zova

JSON output includes cli_json_version = 1. CLI output is bounded and avoids printing object bytes, chunk bytes, vector values, private schema SQL, and user row values.

Bindings

Rust

Rust users normally use the safe crate:

[dependencies]
zova = "0.21.0"

The lower-level raw FFI crate is available as:

[dependencies]
zova-sys = "0.21.0"

zova exposes Database for single-owner code and SharedDatabase for an opt-in cloneable Send + Sync handle. One shared handle is safe and internally serialized; open multiple handles for true SQLite concurrency.

Existing Rust object and vector APIs transparently use a bound store after the database is opened. Store create/bind/unbind/split management remains native-Zig/CLI-only in v0.21.

Python

Install from PyPI:

uv add zova

The Python package is a PyO3/maturin extension backed by the Rust zova crate. It exposes records, prepared statements, transactions, savepoints, app events, backup, compact, restore, objects, ObjectWriter, vectors, and SQL-native vector search.

The package is source-first in 0.21.0. Installs may build the native extension locally and require Rust, Zig, and a C compiler. No official wheel matrix is promised yet.

Existing Python object and vector APIs transparently use a bound store after the database is opened. Store create/bind/unbind/split management remains native-Zig/CLI-only in v0.21.

Go

Install:

go get github.com/atasesli/zova/bindings/go@v0.21.0

Import:

import zova "github.com/atasesli/zova/bindings/go"

The Go package uses cgo over include/zova.h and links libzova_c.a. Build the C ABI first in this repository:

zig build c-abi

Existing Go object and vector APIs transparently use a bound store after the database is opened. Store create/bind/unbind/split management remains native-Zig/CLI-only in v0.21.

External Go projects should point cgo at an installed Zova C ABI:

CGO_CFLAGS="-I/path/to/zova/include" \
CGO_LDFLAGS="-L/path/to/zova/lib -lzova_c" \
go test ./...

C ABI

The C ABI is the language-neutral integration layer:

#include "zova.h"

It uses opaque handles, request structs, fixed-width ids, explicit free functions, and zova_status return codes. Returned buffers, messages, manifests, vectors, collection lists, and search results are owned by Zova and must be freed with the matching zova_*_free function.

One zova_database * handle is internally serialized. Calls on the same handle run one at a time. Multiple handles are the path for true concurrency and follow normal SQLite locking behavior.

Zig

Zig users can import the package and use the native facade:

const zova = @import("zova");

var db = try zova.Database.create("app.zova");
defer db.deinit();

The thin SQLite wrapper is also public as zova.sqlite.

Build From Source

Build the CLI:

zig build

Run it:

zig build run

Build the C ABI:

zig build c-abi

Run the C ABI smoke tests:

zig build c-abi-test

Run Rust checks:

cargo test --workspace --manifest-path bindings/rust/Cargo.toml

Run Go checks after building the C ABI:

zig build c-abi
cd bindings/go
go test ./...

Run Python checks:

uv run --isolated --with maturin --with pytest --directory bindings/python maturin develop
uv run --isolated --with pytest --directory bindings/python python -m pytest

SQLite Policy

Zova does not hide SQLite. SQL remains SQLite SQL, locking remains SQLite locking, and PRAGMAs remain application policy.

Zova does not silently enable PRAGMA foreign_keys = ON, does not run VACUUM automatically, does not enable auto_vacuum, and does not change journal or synchronous settings automatically.

Current Boundaries

Zova 0.21.0 does not include:

• binding-level app-registered extension authoring APIs
• binding-level dynamic .zovaext loading APIs
• ANN indexes such as HNSW or IVFFlat
• vector SQL operators
• object or chunk virtual tables
• Cypher, GQL, Gremlin, SPARQL, or Neo4j compatibility
• automatic graph extraction from SQL, documents, or LLM output
• embedding generation
• TypeScript or Swift bindings
• a Python wheel matrix
• background worker threads hidden inside Zova
• cross-process notifications, durable notification replay, or automatic mutation logging
• in-place repair
• overwrite mode for backup/compact/restore/salvage
• bundle backup or multi-file restore packages
• multiple named object/vector stores or routing rules
• automatic bound-store path repair
• C ABI, Rust, Go, or Python store-management APIs
• remote sync, S3 compatibility, NATS integration, or Redis-like behavior
• compiled release artifacts

Diagnostics and salvage are CLI-first in this release. Bindings should not parse human text output as a stable library contract.

Testing

Run the core tests:

zig build test
zig build e2e
zig build cli-test
zig build c-abi-test

Run the full release smoke:

scripts/check-release.sh

Release Package Policy

Zova releases source packages. The source archive includes:

• README.md
• LICENSE
• build.zig
• build.zig.zon
• docs
• scripts
• bindings/rust
• bindings/go
• bindings/python
• include
• src
• tests
• vendor

Compiled CLI binaries, compiled C ABI libraries, Rust target directories, Go build outputs, Python wheels, Python native extensions, and cache directories are not release artifacts.

Release command:

scripts/package-release.sh 0.21.0

Distribution command for crates.io and PyPI, in that order:

scripts/distribute-release.sh 0.21.0

The Go module tag is created and pushed by scripts/package-release.sh.

Do not run release or distribution commands until the exact commit is ready to tag and publish.

License

Zova is MIT licensed. See LICENSE.

SQLite is vendored in vendor/sqlite3.53.2 and is public domain.