db-sdk
Early — documentation first

Safely read databases through one interface.

A provider-agnostic TypeScript SDK for connecting to databases whose schema you don't control at compile time: customer stores, cross-engine tools, or AI-generated queries.

Shared lifecycle. Native queries.

Postgres speaks SQL. Firestore does not.

test, introspect, query, and close are the same for every provider. The query input is not. DB SDK does not translate one language into another.

PostgreSQLintended API
import { connect } from "db-sdk";
import { postgres } from "@db-sdk/postgres";

const db = await connect({
  provider: postgres({
    connectionString: process.env.DATABASE_URL,
  }),
});

await db.test();
const catalog = await db.introspect();
const users = await db.query({
  sql: "SELECT id, email FROM users WHERE plan = $1",
  params: ["pro"],
});
Firestoreintended API
import { connect } from "db-sdk";
import { firestore } from "@db-sdk/firestore";

const db = await connect({
  provider: firestore({
    serviceAccount: process.env.FIREBASE_SERVICE_ACCOUNT,
  }),
});

const sessions = await db.query({
  collection: "sessions",
  filters: [{ field: "plan", op: "==", value: "pro" }],
  limit: 20,
});

For databases you did not design

ORMs assume you chose one engine and wrote the schema. Many products cannot do that.

Customer databases
A product attaches to each customer’s Postgres, Firestore, or other store at runtime. The schema is discovered after they connect.
Cross-engine tools
Investigation consoles and internal tools work across engines. Adding an engine should mean adding a provider, not rewriting the host.
AI-generated queries
The app owns the model and the API key. DB SDK takes the catalog out, treats the query as untrusted input, and runs a bounded read.

Not an ORM. Not an AI framework.

If Postgres is your application database, use an ORM. If the product must attach to someone else’s database — or several in one workflow — use DB SDK. Query generation stays in the application. The SDK does not take an AI API key.

Contrast
ORMDB SDK

Whose database?

Yours

Often the customer’s

When is the schema known?

Compile time, in a file you wrote

Runtime, after introspect()

Do engines change?

Rarely; you picked one

Per connection, at runtime

Query style

Typed API from your schema

Provider-native, then validated

Writes and migrations

Yes

Out of scope

One lifecycle, many providers

Open more than one connection in the same request. DB SDK does not merge stores. It makes each independently testable, introspectable, and readable.

  1. 1

    connect

    Turn credentials into a handle. Does not create a database.

  2. 2

    test

    Prove the credential works before the host saves it.

  3. 3

    introspect

    Return a catalog: namespaces, tables or collections, fields.

  4. 4

    query

    Run a provider-native read and return a shared result envelope.

  5. 5

    close

    Release the client when the work is done.

Treat generated queries as untrusted

DB SDK is designed to read, not write. SDK validation is not enough — especially for SQL. Prefer a read-only database user.

SDK
Read-oriented API, abort, default time and row limits. Fail closed when unsure. Not a security boundary.
Provider
Engine-specific checks. SQL policy for Postgres. Read APIs only for Firestore. Not a security boundary.
Runtime
Timeouts, required or injected limits, bounded result payloads.
Database
The lock: a dedicated read-only role or IAM principal, restricted schemas, TLS.