Explore the directory
Skip to article
Database

Database

A database SDK carries more than queries. It also carries a connection model, an authorization model, and consistency guarantees your application relies on.

On this page

Choose the access model

Start by deciding where queries run and whose identity they use. A browser data client, a server-side ORM, and a direct database driver solve related problems with different security and deployment requirements.

OptionEvaluate first
Browser data clientUser identity, row-level authorization, exposed schema, and permitted operations.
Server-side ORMSchema and migration workflow, generated types, transactions, and runtime support.
Native driverConnection lifecycle, pooling, parameterized queries, and database-specific features.
HTTP database clientRequest semantics, transaction support, connection behavior, and service limits.

Preserve authorization

In a browser integration, access must be enforced by the data service rather than a hidden UI control. Supabase's row-level security guide explains how database policies control access and why privileged service credentials must stay off the frontend.

Model product operations

App-owned repository boundary · illustrative
type Project = { id: string; name: string };
type Actor = { userId: string; tenantId: string };

interface ProjectRepository {
  listForActor(input: {
    actor: Actor;
    limit: number;
    cursor?: string;
  }): Promise<{
    projects: Project[];
    nextCursor?: string;
  }>;
}

// Implement authorization, stable ordering, and cursor
// semantics in the adapter for your actual database.

Avoid a universal query object that pretends every database has the same joins, filters, ordering, or consistency. Keep product operations narrow and retain a native path for database-specific queries.

Transactions and recovery

Use a real transaction for operations that require multiple writes to commit together. Check the installed client's transaction API, supported engines, and isolation behavior. The Prisma transaction documentation is an example of a primary reference to consult for a specific client.

Do not automatically fall back to another database after a failed write. A timeout leaves the original write's outcome uncertain, and a second database may have different state. Use durable operation identifiers and a deliberate reconciliation process.

Test real database semantics

  • Unit-test product behavior with deterministic repository fakes.
  • Use an isolated real database to verify constraints, authorization, transaction rollback, and query behavior.
  • Exercise pagination while records are inserted or deleted.
  • Check the connection and concurrency model in the actual deployment environment.

SDK SDK is an independent discovery hub. Provider examples link to official documentation. App-owned examples are illustrative patterns you can adapt.