v0.1.1

v0.1.1 is a packaging release. The server behavior is the same as v0.1.0; what changes is how you get it and how it reports itself.

Install it the way you prefer

One tag now produces every common install artifact:

• Prebuilt archives for Linux (amd64, arm64, arm v7, 386), macOS (amd64, arm64), Windows (amd64, arm64), and FreeBSD (amd64, arm64).
• .deb, .rpm, and .apk packages.
• A multi-arch container image at ghcr.io/tamnd/dbrest for linux/amd64 and linux/arm64.

docker run -p 3000:3000 \
  -e DBREST_DB_BACKEND=sqlite \
  -e DBREST_DB_URI='file:/data/example.sqlite' \
  ghcr.io/tamnd/dbrest

Or with the Go toolchain:

go install github.com/tamnd/dbrest/cmd/dbrest@latest

The Homebrew tap and Scoop bucket entries come online as those repositories are set up; the release does not wait on them.

What every release carries

Each release ships a checksums.txt (sha256), a CycloneDX SBOM for every archive, and a keyless cosign signature over the checksums. The container image is signed too.

The binary now reports its build

dbrest --version prints the version, the commit it was built from, and the build date. A go build or go run with no version stamp falls back to the module version from the build info, so it still says something useful.

Windows builds now

The schema and config reload signals (SIGUSR1, SIGUSR2) do not exist on Windows, which kept the Windows targets from compiling. The signal handler moved to a Unix-only file with a no-op elsewhere. Reload still works on every platform through the db-channel listener and the admin API; only the signal path is Unix-only.

Pure-Go all the way down

The SQLite backend uses pure-Go modernc.org/sqlite, so the whole release matrix is CGO-free and cross-compiles from a single runner.

v0.1.0

dbrest speaks the PostgREST v14 HTTP API on top of a database you pick. The HTTP contract stays put (the URL grammar, the filter operators, resource embedding, the Prefer headers, the error envelopes, the OpenAPI root) while the engine underneath is swappable behind one backend interface.

This is the first tagged release. We cut it now because the PostgreSQL backend has been audited against PostgREST v14 end to end and every finding is closed.

How it is built

The server is one engine-agnostic frontend (parse the request into an IR, plan it against a unified schema model, authorize, render) and a set of backends that lower that IR to a concrete engine. The frontend never branches on the engine. It reads each backend's declared capabilities and either lowers a feature natively, rewrites an emulated one, or rejects an unsupported one with a precise error. Adding a database is implementing one interface, not forking the server.

Backends in this release

• PostgreSQL is the reference oracle, the engine PostgREST itself targets. dbrest aims to emit almost the same SQL and to shape results and errors the same way. It runs live, with integration tests gated on a real server.
• SQLite is the embedded backend the conformance harness diffs against.
• MySQL/MariaDB, SQL Server, and MongoDB have their dialects in place. MongoDB is the odd one out: it does not use the SQL compiler at all and lowers a read to a $match/$sort/$skip/$limit/$project pipeline.

What works across the frontend

• Reads with the full horizontal-filter grammar, and/or/not trees, ordering with PostgreSQL NULLS placement, and limit/offset paging with Content-Range and the 200/206 split.
• Writes (insert, update, upsert, delete) with the PostgREST status rules, the Location header on a single insert, and constraint failures mapped to the right SQLSTATEs.
• Resource embedding over introspected foreign keys, assembled as JSON, with PGRST200/PGRST201 for the missing and ambiguous cases.
• Content negotiation beyond JSON: the singular object type, text/csv, and the scalar octet and text types.
• RPC at /rpc/<fn> chosen by volatility, read-only versus read-write transactions, post-filtering a table return, and PGRST202 when nothing matches.
• JWT authentication (HMAC, RSA, ECDSA) with pinned algorithms, the standard claim checks, the role claim with nested-path support, and a bounded verification cache that never extends a token's lifetime.
• Authorization and RLS emulation: table and column privileges gate every read and write, a * projection is narrowed to the granted columns, and a policy predicate is AND-ed above the whole client filter so a client cannot OR its way past it.
• Full-text (fts/plfts/phfts/wfts) and regex (match/imatch) operators, parsed identically on every backend.
• The Swagger 2.0 OpenAPI root at GET /, where each column advertises only the operators the active backend can actually serve.
• A flat PostgREST-style config file layered with the environment, settable under both the PGRST_* and the native DBREST_* spellings.

PostgreSQL v14 compatibility

Most of the work behind this release was a differential audit of the PostgreSQL backend against a live PostgREST 14 over the same database, across four reports (dialect and SQL lowering, the session and transaction and security model, introspection and RPC and result passthrough, and an empirical live run). Every finding is now closed with tests, the database-touching ones backed by live integration tests gated on DBREST_PG_DSN. The last pieces to land:

• The native RPC path: the function half of the schema cache, argument routing, post-filters honored on POST /rpc, and the volatility-driven access mode.
• The per-request session: SET LOCAL ROLE, the request GUCs, the per-role settings replay, and the hoisted transaction settings.
• Data representations: the from-text and to-json casts applied across the operator surface PostgREST applies them to, with like/ilike and full text correctly left raw.
• Reload over db-channel: a LISTEN connection that re-introspects on reload schema and re-reads config on reload config, reconnecting with backoff.
• The exec mode wired to db-prepared-statements, with an explicit DSN choice still winning.

Running it

cat > dbrest.conf <<'EOF'
db-backend  = "sqlite"
db-uri      = "file:./example.sqlite"
server-port = 3000
EOF

go run ./cmd/dbrest -config dbrest.conf

Then query it the way you would query PostgREST.

Honest scope

This is an early release built subsystem by subsystem against a complete design spec. SQLite and PostgreSQL are the furthest along. The MySQL, SQL Server, and MongoDB data planes (live Execute and introspection) are follow-on work, since each needs a running server to test. The conformance golden side is a checked-in recorded corpus today; the live PostgreSQL-plus-PostgREST capture lands with the container CI matrix.