The Sequelforge DSL

Sequelforge schemas are plain text. You declare Tables, optionally connect them with References, and the diagram updates as you type. Here is the smallest useful schema:

Table users {
  id     uuid         [pk]
  email  varchar(255) [unique, not null]
}

Paste that into the editor and you immediately get a table card with a primary key and a unique, non-null column.

A table has a name and a body of columns. Each column is a name, a type, and an optional list of attributes in square brackets.

Table products {
  id          uuid          [pk]
  sku         varchar(64)   [unique, not null]
  name        varchar(160)  [not null]
  price_cents int           [not null]
  active      boolean       [not null, default: true]
}

Tables can live in a schema and carry an alias for use in references:

Table shop.orders as O {
  id  uuid  [pk]
}

Any identifier is accepted as a type, so you are never blocked. These map to native PostgreSQL types on export, optionally with length/precision arguments like varchar(255) or numeric(10, 2).

Marking an integer column with increment exports it as SERIAL / BIGSERIAL.

Attributes go inside [ ], separated by commas. They fine-tune constraints and metadata for a column.

Table orders {
  id          uuid         [pk]
  user_id     uuid         [ref: > users.id, not null]
  status      order_status [not null, default: 'pending']
  total_cents int          [not null]
  placed_at   timestamptz  [not null, default: now(), note: "UTC"]
}

Relationships can be written inline on a column (ref:)or as a standalone Ref statement. The operator encodes the cardinality:

// Inline, on the column:
Table posts {
  id      uuid [pk]
  author  uuid [ref: > users.id]
}

// Standalone, optionally named:
Ref fk_posts_author: posts.author > users.id

Annotate a relationship with explicit (min,max) cardinalities per end, plus an optional label (the relationship verb). from is the source end (the table holding the foreign key), to is the target end. max may be a number, N, or * for “many”.

Table projects {
  id    uuid         [pk]
  owner uuid         [ref: > employee.id,
                      from: (1,1), to: (0,*), label: "manages"]
}

// or on a standalone Ref:
Ref: projects.owner > employee.id [from: (1,1), to: (0,*), label: "manages"]

Read it look-here: a project participates in (1,1) “manages” relationships (exactly one employee), while an employee participates in (0,*) (any number of projects). If you omit the cardinalities, Sequelforge derives sensible defaults from the operator and the not-null status of the foreign key.

Use the toolbar switch to flip the whole diagram between the two notations:

Standalone references accept delete and update actions, exported as ON DELETE / ON UPDATE clauses.

Ref: order_items.order_id > orders.id [delete: cascade]
Ref: orders.user_id > users.id [delete: restrict, update: no action]

Valid actions: cascade, restrict, set null, set default, no action.

A generalization relates a supertype to a set of subtypes (an IS-A hierarchy). Declare the supertype, then list its subtypes. Two constraints describe the set:

Table person {
  id    uuid         [pk]
  email varchar(255) [unique, not null]
}

Table employee { id uuid [pk]  hired_on date }
Table customer { id uuid [pk]  loyalty_points int }

Generalization person [disjoint, total] {
  employee
  customer
}

In the diagram, subtypes connect into a circular hub marked d (disjoint) or o (overlapping); a total generalization doubles the hub's ring, and a hollow triangle points at the supertype. On export, each subtype key becomes a foreign key to the supertype key (table-per-type).

A weak entity has no identity of its own. It is identified by an owning (identifying) entity plus a partial key (discriminator). Prefix the table with Weak and name the owner with depends on:

Table projects {
  id   uuid         [pk]
  name varchar(160) [not null]
}

Weak Table task depends on projects {
  project_id  uuid         [ref: > projects.id, not null]
  number      int          [partial key]
  title       varchar(160) [not null]
}

Weak entities are drawn with the classic ER double border, the partial key gets a dashed underline, and the identifying relationship to the owner is a double line. On export, the weak entity's primary key becomes the composite of the owner's foreign key and the partial key — here (project_id, number).

Add an indexes block inside a table. Single or composite columns are supported, each with optional unique and a custom name.

Table orders {
  id        uuid        [pk]
  user_id   uuid        [not null]
  placed_at timestamptz [not null]

  indexes {
    (user_id, placed_at) [name: 'idx_orders_user_placed']
    user_id [unique]
    placed_at
  }
}

Declare an enum and use its name as a column type. On export it becomes a PostgreSQL CREATE TYPE ... AS ENUM; the other dialects (MySQL 8, SQL Server, Oracle, SQLite) map it to an inline ENUM or a CHECK constraint.

Enum order_status {
  pending
  paid
  shipped
  cancelled [note: "terminal state"]
}

Groups are a visual aid — they bundle related tables together without affecting the generated SQL.

TableGroup commerce {
  orders
  order_items
  products
}

Three comment styles are supported and ignored by the parser.

// a line comment
# also a line comment
/* a
   block comment */

Everything together — the same schema that loads by default in the editor.

Enum employment_type {
  full_time
  part_time
  contractor
}

Table person {
  id    uuid         [pk]
  email varchar(255) [unique, not null]
}

Table employee {
  id       uuid            [pk]
  hired_on date            [not null]
  kind     employment_type [not null]
}

Table customer {
  id             uuid [pk]
  loyalty_points int  [not null, default: 0]
}

Generalization person [disjoint, total] {
  employee
  customer
}

Table projects {
  id    uuid         [pk]
  name  varchar(160) [not null]
}

Weak Table task depends on projects {
  project_id uuid         [ref: > projects.id, not null]
  number     int          [partial key]
  title      varchar(160) [not null]
}

Drop a set of Flyway migration scripts on /timeline and watch your schema evolve version by version: each migration is applied in order and the diagram animates from one version to the next, with a diff of what changed between them.

Files follow the standard Flyway naming convention V<version>__<name>.sql and are replayed in version order (so V2 runs before V10). All five SQL dialects — PostgreSQL, MySQL 8, SQL Server, Oracle, and SQLite — are supported, and the dialect is auto-detected, just like SQL import.

V1__init.sql
V2__add_orders.sql
V3__order_status_enum.sql
V10__drop_legacy_columns.sql

Between any two versions, the diff highlights: