A new standard for database design.
Drawn by you. Driven by your agent.

Three views of one schema, a layout that re-packs itself, and MongoDB documents drawn as documents. Your agent drives the same canvas over MCP — and the arrangement you made survives every edit it makes.

opens preloaded·no signup·free to use
-- view modes

You design a schema in three passes. So it has three views.

Every other tool draws one diagram and leaves you to squint past the columns you are not thinking about. This one draws the amount you need right now, and re-packs the layout every time you switch — so nothing overlaps and nothing needs tidying by hand.

Open(opens in a new tab)
user
4
product
4
order
5
order_item
5
payment
4
-- auto layout

Then it gets messy. One key fixes it.

Half an hour into a design the cards are wherever you dropped them and the edges cross twice on the way. Press the button — or Tidy on the canvas — and the whole thing re-columns itself.

Open(opens in a new tab)
user
4
PK
id
uuid
email
varchar
full_name
varchar
role
enum
product
4
PK
id
uuid
sku
varchar
title
varchar
price
decimal
order
5
PK
id
uuid
FK
user_id
uuid
status
enum
total
decimal
placed_at
timestamp
order_item
5
PK
id
uuid
FK
order_id
uuid
FK
product_id
uuid
qty
int
unit_price
decimal
payment
4
PK
id
uuid
FK
order_id
uuid
amount
decimal
status
enum
01

Columns by dependency, not by name.

Each model lands in a column equal to the longest foreign-key path reaching it, so what a thing depends on is always to its left.

02

Cycles do not break it.

A self-reference has no depth and a loop has no beginning, so the edge closing one is ignored. A schema with a `parent_id` lays out like any other.

03

It lands on the grid.

Positions snap to the dots you can see, so a tidied layout is one you keep dragging from rather than one that jumps when you touch it.

-- mongodb & documents

A document is not a table with a JSON column.

Nesting is how a document database models the world — MongoDB and DynamoDB keep the shape inside the record, not in a join. Most ERD tools let you name a field `JSONB` and leave you there, so that shape stays your problem and the diagram is a lie by omission. Scroll, and watch this one draw the document instead.

Open(opens in a new tab)
customer
3
PK
_id
objectid
email
varchar
full_name
varchar
product
4
PK
_id
objectid
sku
varchar
title
varchar
price
decimal
order
4
PK
_id
objectid
FK
customer_id
objectid
status
enum
total
decimal
-- focus

Point at one thing. The rest steps back.

A schema past twenty models is mostly noise to whatever you are currently thinking about. Focus is the answer to that: everything one hop from what you are pointing at stays lit, everything else dims. Pick a target and watch the canvas.

Open(opens in a new tab)
user
4
PK
id
uuid
email
varchar
full_name
varchar
role
enum
product
4
PK
id
uuid
sku
varchar
title
varchar
price
decimal
order
5
PK
id
uuid
FK
user_id
uuid
status
enum
total
decimal
placed_at
timestamp
order_item
5
PK
id
uuid
FK
order_id
uuid
FK
product_id
uuid
qty
int
unit_price
decimal
payment
4
PK
id
uuid
FK
order_id
uuid
amount
decimal
status
enum
-- hide relations

One table is touching everything. Hide its relations.

In this ride-hailing schema `user` is an endpoint of 7 of the 8 relations — riders, drivers, referrals and both sides of every rating all point back at it. Nothing is wrong with the model; it is just drowning out the structure you were trying to read.

Open(opens in a new tab)
user
8
FK
referred_by_id
uuid?
driver
9
FK
user_id
uuid
vehicle
10
trip
10
FK
rider_id
uuid
FK
driver_id
uuid?
FK
vehicle_id
uuid?
payment_method
9
FK
user_id
uuid
rating
8
FK
trip_id
uuid
FK
rater_id
uuid
FK
ratee_id
uuid
-- versions & compare

See what changed, on the diagram itself.

Schema history usually means a wall of migration files and a guess about what they did to the shape of things. Name a save point, pick any two, and the canvas draws the answer.

v4 · catalogue
v5 · coupons
v6 · naming pass
v7 · payments
Open(opens in a new tab)
user
4
PK
id
uuid
email
varchar
~
full_name
varchar
role
enum
product
4
PK
id
uuid
sku
varchar
title
varchar
price
decimal
order
5
PK
id
uuid
FK
user_id
uuid
status
enum
total
decimal
placed_at
timestamp
order_item
5
PK
id
uuid
FK
order_id
uuid
FK
product_id
uuid
qty
int
+
unit_price
decimal
payment
ADDED
+
id
uuid
+
order_id
uuid
+
amount
decimal
+
status
enum
coupon
REMOVED
id
uuid
code
varchar
percent_off
int
-- mcp & realtime

You, your team, and your agent. One canvas, live.

An MCP server and a skill ship with it. Your agent’s edits arrive through the same path a teammate’s do — so what it changes appears on everyone’s canvas as it happens, and your arrangement survives all of it.

Add shipments — an order can have many, each with a carrier, a tracking code and a status.
hellodb.create_model { name: "shipment" }
hellodb.create_relation order.id → shipment.order_id
hellodb.add_fields shipment { carrier, tracking_code, status, shipped_at }
done · 1 model, 1 relation, 4 fields · 0 models moved
user
4
PK
id
uuid
email
varchar
full_name
varchar
role
enum
product
4
PK
id
uuid
sku
varchar
title
varchar
price
decimal
order
5
PK
id
uuid
FK
user_id
uuid
status
enum
total
decimal
placed_at
timestamp
order_item
5
PK
id
uuid
FK
order_id
uuid
FK
product_id
uuid
qty
int
unit_price
decimal
payment
5
PK
id
uuid
FK
order_id
uuid
amount
decimal
status
enum
refunded_at
timestamp
shipment
6
PK
id
uuid
FK
order_id
uuid
carrier
varchar
tracking_code
varchar
status
enum
shipped_at
timestamp
YOUANRV

The canvas is already open.

Just draw — or tell your agent to. No account, no card.

-- signing up takes 0 seconds. there isn't one.