Technology · Framework

sqlx

sqlx carries my Rust services' PostgreSQL access; where no table is known at compile time, I check against the schema itself instead.

FAFO Core · Helix · Agent SwarmRuntime query APIpgvector
A name in · a typed query out

Runtime queries checked against the catalog

FAFO Core and Function Forge has a database layer where no table is known at compile time, so I built it on sqlx's runtime query API. Every operation takes a view or table name as a string and reads its shape from PostgreSQL's system catalogs, cached with vector dimensions and array element types. See Tools that build tools, under governance.

The usual pathThe runtime path, rebuilt
No table is known when a generated function is compiled. Names pass a resolver check and are quoted, values never enter the SQL text, and function code never gets a raw pool.

I know the trade-offs inside a Rust database toolkit well enough to take the runtime path on purpose and rebuild the safety it gives up.

One owner for a store's SQL

Helix needed one owner for the SQL of its collaboration store. A dedicated sqlx crate holds all PostgreSQL access for the collaboration shell, the other services call its typed store functions, and its schema evolves through numbered migrations.

the store crate
Services above, the collaboration store below; no service holds a query of its own.

Single-statement writes under concurrency

Agent Swarm uses the Rust PostgreSQL clients in the services that write agent state, where many events land at once and each write must be exact.

Conflict-aware inserts reserve launches; presence-aware upserts write presence.

sqlx is third-party; the schema resolution, the type-directed binding and the boundary around generated code are mine.