Core idea
Connect, describe, and read a database whose schema you don't control at compile time — without turning every driver into SQL.
docs/core-idea.mdDB SDK is a runtime database adapter. It gives an application one way to connect, describe, and safely read a data store — including a store it only learned about at runtime.
Not an ORM
If Postgres is your application database, use an ORM. If the product must attach to someone else's database — or to several different ones in one workflow — use DB SDK.
| ORM | DB SDK | |
|---|---|---|
| Whose database? | Yours | Often the customer's |
| When is the schema known? | Compile time, in a file you wrote | Runtime, after introspect() |
| Do drivers change? | Rarely; you picked one | Per connection, at runtime |
| Query style | Typed API generated from your schema | Provider-native, then validated |
| Writes and migrations? | Yes | Never — query-only |
Not an AI framework
DB SDK does not talk to a model and does not take an AI API key. An AI-powered host may call introspect(), let its own model draft a provider-native query, then send that query to DB SDK. The generated query is untrusted input — the same as a query typed by a human.
Shared lifecycle, native queries
Every provider implements the same verbs. The catalog is shared so UIs and models have one picture of what exists. The query language is not. PostgreSQL takes SQL. Firestore takes collection queries. Hosted providers (Supabase) open a shared driver (Postgres).
connect({ provider }) → test → introspect → query → closeKeep going
Guide
Who it's for
Runtime access to customer databases, cross-driver tools, and AI hosts that need a catalog and a bounded read — not an ORM.
Guide
Architecture
One core, drivers for database types, hosted providers that reuse a driver. Shared lifecycle, native queries, one catalog shape.
Pattern
Attach a customer database
Resolve the provider from stored config, prove the credential works, then introspect the schema after they connect.