Firestore driver
First document driver: catalog from collections and samples, read APIs only, required limits — never SQL-over-Firestore.
Firestore is the other first driver. It exists so the core cannot quietly become “SQL with adapters.” Catalog from collections and samples, read APIs only, required limits.
import { connect } from "@db-sdk/core";
import { firebase } from "@db-sdk/firebase";
const db = await connect({
provider: await firebase({
accessToken,
projectId,
}),
});
const sessions = await db.query({
collection: "sessions",
filters: [{ field: "plan", op: "==", value: "pro" }],
limit: 20,
});Intended query controls
- Call read APIs only — never set, update, delete, or writeBatch
- Require a collection from the catalog or an explicit allow list
- Require a limit on every query
- Infer schema by sampling, not by downloading the collection
Do not add Firestore by extending a SQL sanitizer. Add @db-sdk/firestore with its own read-only checks. Prefer a read-only IAM principal, not Editor.
Keep going
Reference
Postgres
First SQL driver: connection, introspection from information_schema, parameterized SELECT, limits and timeouts.
Guide
Architecture
One core, drivers for database types, hosted providers that reuse a driver. Shared lifecycle, native queries, one catalog shape.
Pattern
Query two drivers in one workflow
Open two stores in the same workflow. Same verbs, each driver's native query shape. The SDK does not translate one language into the other.