noorm — Write SQL. Skip the ORM.

Skip to content

Appearance

V1.0 · APACHE 2.0 · POSTGRES · MYSQL · SQLITE · MSSQL<br>noormWrite SQL. Skip the ORM.<br>The raw SQL manager people keep asking for. Schema in files, changes in git, one CLI to prod.<br>Get started →<br>View on GitHub

single binary·zero dependencies at runtime·type-safe SDK

bash · install.sh copy<br># Install (no sudo)<br>$ curl -fsSL https://noorm.dev/install.sh | sh

$ cd /my/project && noorm init<br>$ npm i @noormdev/sdk

$ noorm run build

Schema lives in SQL files<br>Your SQL files are the current schema. Fresh databases build from them in seconds. Existing ones catch up through versioned changes.<br>How it works

Real relational design<br>Compound keys, inherited keys, check constraints, subtype clusters. Model what your data actually is instead of one surrogate ID per table.<br>The case for it

Procedures, functions, TVFs<br>Call stored procedures from TypeScript with typed params and result rows. Table-valued parameters included. The bridge ORMs never built.<br>SDK reference

Data pipelines<br>Move data between databases in foreign-key order, across dialects, or out to portable files. Seed a QA environment from staging in one command.<br>Transfer data

Safe to point an agent at<br>An MCP server exposes noorm to coding agents behind per-channel access roles. Admin at your terminal, read-only for the agent, invisible for prod.<br>AI integration

One CLI, not five tabs<br>Schema explorer, SQL terminal, encrypted vault, dynamic templates. Every command runs headless and emits JSON you can pipe into CI.<br>CLI reference

Why noorm? ​<br>Migration tools make you describe your schema twice: once in the migrations that built it, and once in your head. The current state only exists if you replay every file in order, and the moment you need a compound key or a trigger you are writing raw SQL inside a wrapper that was designed to keep you away from it.<br>noorm inverts that. Your SQL files are the current schema. A fresh database runs them and is done. An existing database gets to the same place through changes — small forward/revert pairs that noorm tracks, checksums, and applies in order.<br>Everything else follows from that split:<br>Stages keep dev, staging, and production configs apart, with access roles per environment<br>Templates let one SQL file render differently per environment<br>The SDK wraps it all in a type-safe client — Kysely queries, stored procedures, and TVFs<br>Headless mode makes every command scriptable, with --json on anything worth parsing<br>noorm is the fifth attempt at this problem, and every feature in it exists because working without an ORM was worse without it. Why noorm is the longer version of that story.<br>Quick start ​<br>bash# Install (no sudo needed)<br>curl -fsSL https://noorm.dev/install.sh | sh

# Or via npm<br>npm install -g @noormdev/cli

# Bootstrap a project<br>cd /my/project && noorm init<br>Corporate network?<br>If noorm.dev is blocked, install from the GitHub mirror:<br>bashcurl -fsSL https://raw.githubusercontent.com/noormdev/noorm/master/install.sh | sh

Write a SQL file, then build it:<br>bashmkdir -p sql/01_tables<br>echo "CREATE TABLE users (id SERIAL PRIMARY KEY, name TEXT);" > sql/01_tables/001_users.sql

noorm run build<br>✓ Executed 1 file<br>When the schema evolves, update the SQL file and add a change. The file keeps describing what the schema is; the change tells existing databases how to catch up:<br>bash# Edit sql/01_tables/001_users.sql to add an email column<br># Add changes/2024-01-add-email/forward.sql

noorm change ff # fast-forward: apply pending changes<br>A fresh database skips all of that — it just runs the files:<br>bashnoorm config use test<br>noorm run build # fresh DB gets the current schema directly<br>SQL files = current schema. Changes = how existing databases get there.<br>Setup wizards (config add, config edit, secret management) run in the TUI — launch it with noorm ui. Everything else runs headless:<br>bashnoorm run build # Build the schema from SQL files<br>noorm change ff # Apply all pending changes<br>noorm db explore --json # Inspect the database as JSON<br>noorm vault set API_KEY ... # Push a team secret to the encrypted vault<br>Plan it before you build it ​<br>Most schemas get designed while they are being built, one migration at a time, and nobody outside the code can see the shape until it is already in production.<br>ignatius is the planning half. Describe your entities and processes in markdown and it renders an IDEF1X entity diagram, a searchable data dictionary, and SSADM data flow diagrams that show how data moves between people, the database, caches, files, and paper. Export it to a single HTML file, get agreement from the people who care, then hand the same markdown to your agent as the specification for the SQL.<br>bashcurl -fsSL https://raw.githubusercontent.com/noormdev/ignatius/main/install.sh | sh<br>ignatius serve ./models -o<br>ignatius decides what the data is. noorm builds it. Both keep the source of truth in files you own. See Information modeling.<br>Next steps ​<br>Installation Get noorm installed and...