aquameta.

How it’s built

PostgreSQL, all the way down.

The familiar web stack — ORM, framework, router, build tools — reappears here as a set of PostgreSQL modules. Each is tables, views, and functions.

01

The stack, reimagined as data

Where a traditional stack has libraries, Aquameta has schemas. Each module is just rows and functions in the database.

meta
A read-only lens over the PostgreSQL catalog — every schema object as typed, queryable data.
meta_src
Authored schema as source, with deploy / extract / drift detection. Migrations without a migrations folder.
bundle
Version control for database rows: content-addressed, with commits, history, and time-travel.
endpoint
The HTTP layer — a REST API, routing, and resource serving, implemented entirely in SQL.
template
A server-side template engine with live SQL embedded in the markup.
web
Web standards — MIME types, JS modules, stylesheets, WASM — modeled as relations.
widget
Self-contained UI components stored as rows, bound to data by shape.
event
Real-time change notifications, decoded from the write-ahead log and pushed over WebSockets.
pgfs
Mounts database tables as an editable filesystem — every file is a field.
semantics
Decorates the catalog with human metadata: labels, column types, logical keys.
sidecar
A sandboxed WASM plugin runtime, callable from SQL.
docs
This reference — documentation reflected from the catalog, served by the platform itself.
02

A thin daemon, and nothing else

One small process stands between the network and the database.

A lightweight daemon accepts HTTP requests and hands each one to the database as a query. It carries no application logic — the logic lives in SQL.

Its one clever move is identity. Every request runs as a real PostgreSQL role: the daemon maps a session to a role and routes the request through that role’s own connection pool. So current_user is always correct, which means row-level security and ordinary GRANT permissions simply work — no framework re-implementing auth on top of the database.

03

Edit it live

No build step between you and the running system.

Because code and interface are rows, you change them by changing data. Mount the database as files and edit a widget in your editor; the change is live on save. Version it with a bundle commit when you’re ready.

The reference documentation is the proof of the whole approach: query the catalog for structure, layer prose on top, serve it through the HTTP module that it documents.