Turso, Neon and Supabase

​

Turso and libSQL

pnpm add @glinr/theauth @libsql/client

import { createTheAuth } from "@glinr/theauth";

const auth = await createTheAuth({
  database: {
    provider: "libsql",
    url: process.env.TURSO_DATABASE_URL!, // libsql://my-db-my-org.turso.io
    authToken: process.env.TURSO_AUTH_TOKEN!,
  },
});

import { createClient } from "@libsql/client";
import { drizzle } from "drizzle-orm/libsql";

const client = createClient({ url: "file:replica.db", syncUrl: process.env.TURSO_DATABASE_URL!, authToken: process.env.TURSO_AUTH_TOKEN! });
const auth = await createTheAuth({ database: { drizzle: drizzle(client), dialect: "sqlite" } });

​

Supabase

const auth = await createTheAuth({
  database: { provider: "postgres", url: process.env.SUPABASE_DB_URL! },
});

• Verify properly: download the root certificate from Database settings in the Supabase dashboard and use ?sslmode=verify-full&sslrootcert=/path/to/supabase-root.crt.
• Encrypt without verifying, which is what Supabase’s own require does: ?uselibpqcompat=true&sslmode=require.

• On serverless, keep the pool small. provider: "postgres" opens a pg pool with its default size, so a function that scales to many instances multiplies it. The transaction pooler absorbs that. If you need a size of one, use bring your own Drizzle with new Pool({ connectionString, max: 1 }).
• Do not point theAuth at the auth schema or reuse Supabase Auth tables. theAuth creates its own theauth_* tables in public. Row Level Security is off on them, so do not expose them through the Data API: turn on RLS with no policies, or revoke access for the anon and authenticated roles. Your server connects as a role that bypasses RLS.

​

Neon

pnpm add @glinr/theauth @neondatabase/serverless drizzle-orm

import { createTheAuth } from "@glinr/theauth";
import { Pool } from "@neondatabase/serverless";
import { drizzle } from "drizzle-orm/neon-serverless";

const pool = new Pool({ connectionString: process.env.DATABASE_URL });

const auth = await createTheAuth({
  database: { drizzle: drizzle({ client: pool }), dialect: "postgres" },
});

​

What was run

• libSQL. The store contract suite (runStoreContract, 14 checks) against a real libSQL file database, with the libsql provider and with a bring your own drizzle-orm/libsql handle. It covers 24 parallel callers on one single use row, unique conflicts, an audit chain written by two handles and the hourly budget. Plus a restart that keeps data, and skipMigrations on an existing and an empty database. Not run: a remote Turso database, libsql:// and wss:// URLs, embedded replicas.
• Supabase. The same suite against local Postgres 14 behind PgBouncer 1.26 in transaction pooling mode with max_prepared_statements = 0, three runs, ten parallel callers. Not run: a real Supabase project, Supavisor, sslmode=require against Supabase’s certificates.
• Neon. A scratch project with the packed @glinr/theauth, @neondatabase/serverless 1.2.0 and ws, using the WebSocket Pool through a small local bridge from WebSocket frames to a local Postgres 14 (Neon’s wire protocol is plain Postgres messages inside the frames). Migrations ran, a user, an agent and allow and deny decisions worked, and 24 parallel calls against a budget of 10 admitted no more than 10. Not run: a real Neon endpoint, so the -pooler host, cold starts and Neon’s own proxy are untested. The Neon driver is not a dependency of this repository, so this is a manual check and not part of the test suite.

​

Run the suite against your own database

cd packages/core
THEAUTH_TEST_SUPABASE_URL='postgres://...:6543/postgres?uselibpqcompat=true&sslmode=require' \
  npx vitest run tests/store-contract/hosted.test.ts