Integrations

Integrations are the places where sqlfu deliberately meets another tool’s model instead of asking you to rewrite the rest of your app around sqlfu.

Use this section when the question is “how does sqlfu fit with this other runtime, framework, service, or SDK?” For database-driver setup only, use Guides or the compact Adapters reference.

First-class integration pages

• Better Auth: let Better Auth generate its auth tables into definitions.sql, while sqlfu still owns migration drafts and migration execution.
• Cloudflare / Alchemy: use the sqlfu/cloudflare module to find local Miniflare D1 files, read Alchemy D1 state, or talk to deployed Cloudflare D1 over HTTP.
• Effect SQL runtime: generate query wrappers that return Effect values and read SqlClient.SqlClient from the Effect environment.
• OpenTelemetry: the short path for sending generated query names to OTel spans.

Adjacent integration surfaces

Some integrations are documented where their main decision lives:

• Cloudflare D1 and Cloudflare Durable Objects stay in Guides because they are full runtime setup guides: project shape, config, migrations, and Worker code.
• Observability stays in Features because it documents the whole instrument() hook model, including OpenTelemetry, Sentry, PostHog, and Datadog.
• Runtime validation libraries live in Runtime validation: arktype, valibot, zod, and zod-mini change the generated wrapper boundary.
• Turso, libSQL, Expo SQLite, Bun SQLite, and sqlite-wasm live in Guides because the main work is choosing the runtime adapter.
• Import-path decisions live in Import surface, including sqlfu/cloudflare, sqlfu/api, sqlfu/analyze, and feature subpaths.