FadoDB is an embeddable active document database. An enterprise process is one document: typed fields, Excel-style formulas, a statechart, rules and access. Agents design it and run it. FadoDB computes it deterministically, records every change and answers in SQL.
$ fadodb formula eval \ -var qty:int=3 -var price:money='9.99 PLN' \ 'ROUND(qty * price * (1 - 10%), 2)' 26.97 PLN $ fadodb formula eval -var a:decimal=0.10 -var b:decimal=0.20 \ 'a + b = 0.30' TRUE $ fadodb formula eval -sql duckdb -var due:date \ 'DAYS(due, TODAY())' value (CAST("due" AS DOUBLE) - floor(CAST($now AS DOUBLE) / CAST(86400 AS DOUBLE))) error NULL params now
Most systems split a business process three ways: a schema in the database, logic in application code, approvals in a workflow tool. An agent asked to build that must get all three right, and nobody can read what it built. In FadoDB the whole process is one document, and the engine refuses anything that does not hold together before a row is written.
A process is one JSON document: fields, formulas, states, guards, rules and access. A person reads it in two minutes. An agent writes it in one call. The engine validates it and names the exact place of every problem.
See the documentOne compiled bytecode runs on the Go VM and as generated SQL on SQLite and DuckDB, with the same result. The conformance suite is the specification, and property tests check that the runtimes agree. The browser VM on the same bytecode is designed.
The conformance suitedecimal, int and money are an int64 mantissa at a declared scale. Rounding is written in the formula. Overflow is an error, not a surprise. 0.10 + 0.20 = 0.30, and currencies must agree.
An append-only event log with who, when and the business date a change belongs to. Nothing is ever rewritten. Every class is a SQL table with its full history, and process mining is a query over the log.
ADR-0006, the event logPure Go on the standard library plus SQLite. No cgo in the core. One file on disk, opened from your program. DuckDB analytics and Postgres are separate modules, so the core stays small.
ADR-0002, the dependency budgetMIT licensed and built in the open. Every decision is a public architecture record. Benchmarks are CI gates and their numbers are published with each release. The README says what works today, and nothing more.
The decision recordsAn Invoice, as a document class. Pick a layer to see where it lives. The formulas run today on v0.1.0. The store, the statechart, the rules and the access rules are Phases 2 to 5. in progress
{ "name": "Invoice", "title": "\"Invoice for \" & customer", "variables": { "customer": {"type": "text", "required": true}, "due": {"type": "date", "default": "ADDDAYS(TODAY(), 30)"}, "discount": {"type": "decimal", "scale": 2, "default": "0"}, "lines": { "type": "rows", "schema": {"sku": "text", "qty": "int", "price": "money"} }, "subtotal": {"formula": "SUM(lines.qty * lines.price)"}, "total": {"formula": "ROUND(subtotal * (1 - discount), 2)"} }, "states": {"initial": "draft", "list": ["draft", "submitted", "approved", "paid"]}, "transitions": [ {"name": "submit", "from": "draft", "to": "submitted", "guard": "total > 0"}, {"name": "approve", "from": "submitted", "to": "approved", "guard": "INGROUP(\"finance\")"}, {"name": "pay", "from": "approved", "to": "paid"} ], "rules": [ {"on": "enter", "state": "paid", "do": [{"action": "create", "class": "Receipt", "values": {"invoice": "ID()", "amount": "total"}}]} ], "access": {"read": "INGROUP(\"finance\") OR customer = USER()"} }
The same formulas, the same answers, from a Go program, a SQL client, a browser or an agent. Each dot says how far along that piece is.
v0.1.0 is a pre-release: the command-line tool evaluates formulas on the Go VM and shows the SQL it generates. Nothing stores a document yet.
# Go 1.26 or newer
go install github.com/MojoHand70/fadodb/cmd/fadodb@latestBuilds the fadodb binary into your Go bin directory. fadodb version prints the version, the commit and the build date.
curl -LO https://github.com/MojoHand70/fadodb/releases/download/v0.1.0/fadodb_0.1.0_linux_amd64.tar.gz tar xzf fadodb_0.1.0_linux_amd64.tar.gz ./fadodb version
For arm64 replace amd64 with arm64. Every archive is listed in checksums.txt. Put fadodb on your path.
curl -LO https://github.com/MojoHand70/fadodb/releases/download/v0.1.0/fadodb_0.1.0_darwin_arm64.tar.gz tar xzf fadodb_0.1.0_darwin_arm64.tar.gz ./fadodb version
Apple silicon. On an Intel Mac replace arm64 with amd64. Checksums are in checksums.txt.
# PowerShell
Invoke-WebRequest https://github.com/MojoHand70/fadodb/releases/download/v0.1.0/fadodb_0.1.0_windows_amd64.zip -OutFile fadodb.zip
Expand-Archive fadodb.zip -DestinationPath fadodb
.\fadodb\fadodb.exe versionFor Windows on Arm replace amd64 with arm64. Checksums are in checksums.txt.
$ fadodb formula eval -var name:text=invoice 'UPPER(LEFT(name, 3)) & "-" & TEXT(42)' "INV-42" $ fadodb formula eval -var a:decimal=0.10 -var b:decimal=0.20 'a + b = 0.30' TRUE
Thirteen phases, each ending in a tagged release with its benchmarks published. A phase is never called done before its acceptance criteria pass.
Lexer, parser, binder, bytecode, the Go VM and the SQL generator for SQLite and DuckDB, with the conformance suite as the specification and benchmark gates in CI.
Release notesThe primary-store and point-lookup benchmarks that choose the store, proposed as ADR-0035, SQLite as the transactional store, and ADR-0036, an in-memory index for lookups inside commits.
Decision recordsdecimal, int and money; a date that is a calendar day beside datetime; division by zero as an error, and IFERROR to catch one.
Whether a person ever opens a screen or not.
Decision records, a conformance suite, benchmark gates and a changelog that says what changed. Read along, or start with the formula engine today.