ORM-free applications

​

Directive

​

Why the ORM layer is no longer necessary

• PostgreSQL SQL is the schema contract. Tables, constraints, indexes, views, functions, triggers, grants, RLS, policies, and supported extensions live in the SQL tree. No application DSL has to approximate those objects.
• Migrations come from the same tree. supaschema diff renders guarded SQL from parser-backed model differences, and supaschema check verifies the migration before it reaches a database.
• Apply is part of the workflow. supaschema sync can reconcile target history and apply pending migrations through configured direct PostgreSQL or Supabase CLI runners after safety gates pass.
• Types are generated before deploy. supaschema types writes database.types.ts from the declared schema, so application code can compile against the intended shape before the database has caught up.
• Runtime validation is generated too. database.zod.ts provides a SupaschemaZod runtime object that mirrors schemas, tables, views, enums, and composites.
• Deploy safety is package-owned. The sync pipeline can block type-breaking changes and RLS hazards before mutation, instead of relying on a query layer to notice drift later.

​

Application pattern

import type { Tables, TablesInsert } from "../database.types";
import { SupaschemaZod } from "../database.zod";

type AccountInsert = TablesInsert<{ schema: "app" }, "accounts">;
type AccountRow = Tables<{ schema: "app" }, "accounts">;

export async function createAccount(
  db: { query<T>(sql: string, values: unknown[]): Promise<{ rows: T[] }> },
  body: unknown
): Promise<AccountRow> {
  const input: AccountInsert =
    SupaschemaZod.app.Tables.accounts.Insert.parse(body);
  const result = await db.query<AccountRow>(
    "insert into app.accounts (name) values ($1) returning id, name",
    [input.name]
  );

  return SupaschemaZod.app.Tables.accounts.Row.parse(result.rows[0]);
}

​

Keep one source of truth

​

Related