noormWrite SQL. Skip the ORM.

Why noorm? ​

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.

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.

Everything else follows from that split:

• Stages keep dev, staging, and production configs apart, with access roles per environment
• Templates let one SQL file render differently per environment
• The SDK wraps it all in a type-safe client — Kysely queries, stored procedures, and TVFs
• Headless mode makes every command scriptable, with --json on anything worth parsing

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.

Quick start ​

# Install (no sudo needed)
curl -fsSL https://noorm.dev/install.sh | sh

# Or via npm
npm install -g @noormdev/cli

# Bootstrap a project
cd /my/project && noorm init

curl -fsSL https://raw.githubusercontent.com/noormdev/noorm/master/install.sh | sh

Write a SQL file, then build it:

mkdir -p sql/01_tables
echo "CREATE TABLE users (id SERIAL PRIMARY KEY, name TEXT);" > sql/01_tables/001_users.sql

noorm run build

✓ Executed 1 file

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:

# Edit sql/01_tables/001_users.sql to add an email column
# Add changes/2024-01-add-email/forward.sql

noorm change ff     # fast-forward: apply pending changes

A fresh database skips all of that — it just runs the files:

noorm config use test
noorm run build     # fresh DB gets the current schema directly

SQL files = current schema. Changes = how existing databases get there.

Setup wizards (config add, config edit, secret management) run in the TUI — launch it with noorm ui. Everything else runs headless:

noorm run build             # Build the schema from SQL files
noorm change ff             # Apply all pending changes
noorm db explore --json     # Inspect the database as JSON
noorm vault set API_KEY ... # Push a team secret to the encrypted vault

Plan it before you build it ​

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.

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.

curl -fsSL https://raw.githubusercontent.com/noormdev/ignatius/main/install.sh | sh
ignatius serve ./models -o

ignatius decides what the data is. noorm builds it. Both keep the source of truth in files you own. See Information modeling.

Next steps ​