noorm

Write SQL. Skip the ORM.

A SQL-first schema and change manager for PostgreSQL, MySQL, SQLite, and SQL Server.
Your schema lives in SQL files. noorm builds it, versions it, and keeps every environment in sync.

Documentation · Getting started · Terminal UI · SDK

Install

curl -fsSL https://noorm.dev/install.sh | sh

Or via npm:

npm install -g @noormdev/cli

The install script is fully transparent and open source — it downloads a prebuilt binary from GitHub Releases, built from this repository's source. It installs to a user-writable directory already in your PATH when possible, falling back to ~/.local/bin.

Corporate network? Use the GitHub mirror: curl -fsSL https://raw.githubusercontent.com/noormdev/noorm/master/install.sh | sh

Quick start

# Bootstrap a project — creates your identity and the sql/ and changes/ layout
noorm init

# Add a database config
noorm ui

Adding a config is the one step with no headless equivalent: it needs connection details and a live connection test, so noorm config add sends you to the TUI. From there, [c] Config → [a] Add, then [r] Run → [b] Build to execute your SQL files.

With a config in place, everything else runs headlessly:

noorm run build             # Build the schema from SQL files
noorm change ff             # Apply pending changes
noorm db explore --json     # Inspect the database as JSON

In CI there is no TUI to fall back on, so bootstrap from NOORM_* environment variables instead:

noorm ci init --name ci     # reads NOORM_IDENTITY_* and NOORM_CONNECTION_*
noorm run build

How it works

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.

noorm inverts that.

SQL files	Are your current schema. A fresh database runs them and is done.
Changes	Move an existing database from any state to current — forward/revert pairs that noorm tracks, checksums, and applies in order.
Stages	Keep dev, staging, and production apart, with access roles per environment.
SDK	Wraps it in a type-safe client — Kysely queries, stored procedures, and TVFs.

You write SQL. noorm executes it, tracks what ran, and keeps environments in sync.

Why noorm?

ORMs push you toward a surrogate ID on every table and join-heavy queries. Proper relational design uses inherited keys, basetype-subtypes, and compound constraints — things ORMs can't express, and that migration tools make painful to maintain.

noorm lets you write the SQL your database was designed for, then manages execution across environments.

Read the argument in full: The case for proper relational design

SDK

For programmatic access in your applications:

npm install @noormdev/sdk kysely

Build a dedicated database package with a domain class per area of your schema, each holding a typed Context. Kysely types mirror your database, integration tests run against a real one, and the same package works in servers, workers, and CLIs.

Building your SDK →

Coding agents

If you use an AI coding agent, install the noorm skill so it writes against the real conventions instead of guessing:

npx skills add noormdev/noorm/skills

It teaches the agent the SDK surface, the CLI's headless flags, template syntax, and config layout — the parts that are easy to get subtly wrong.

noorm also runs as an MCP server, behind per-channel access roles: admin at your terminal, read-only for the agent, or invisible entirely.

License

Apache License 2.0. See LICENSE and NOTICE.