DEV Community: erdonline

Can I veto the agent's DDL before it hits main?

erdonline — Sun, 30 Aug 2026 13:09:56 +0000

Two hours before go-live, the DDL lands in the group chat

Thursday, 10 p.m. The release window is 1 a.m. Someone drops alter_orders_v47.sql into the channel: "Agent generated it. CI is green. Can we merge?"

You are the DBA. You are not the Tech Lead who clicked Approve this afternoon — that already happened. You are the last person who can still say no. You open the file: add columns, change types, add indexes, attach foreign keys. The parser is happy. The names look like your team's. You know the things that actually blow up are not in the line numbers: how long this table locks tonight, whether NOT NULL without a default survives old rows, whether down can restore the schema you have now.

You do not have time to stand up a production-sized database and run this ALTER. You also do not have production credentials you are willing to hand an Agent so it can "verify." So the veto shows up two hours before go-live, on a change already sitting in a PR about to hit main — not when the intent was first proposed.

Say no and you look like you are blocking the release. Say yes and the postmortem asks which gate was the gate. Last time it went like this: an add-column on biz_order had no default. Staging was small; it passed. Peak production locked waiters and stopped downstream reconciliation for twenty minutes. That SQL was Approved in the afternoon. You saw it at night. The thing you were supposed to veto arrived two time zones late.

This failure has a name: the veto arrived too late

This is not "the DBA is too slow." It has a name — the veto arrived too late.

Agents write DDL faster; humans still review DDL at the old speed. Intent hides in a SQL file that only enters the group chat after merge is already in motion: you see statements that will execute, not "relative to the last approved version, which three changes did the team actually agree to." By the time you speak, the train is already on the bridge.

A Lead's Approve answers "did I look at this intent?" (that is a different job). The DBA has to answer a different sentence: can I say no to the intent before it hits main? Those are not the same button. Approve is signed on the PR. Veto has to happen before the intent is treated as already human-reviewed.

A red line sits on top of that: production credentials do not belong in the IDE. Banning the Agent from the database does not make intent show up earlier — it just sends the Agent off to invent SQL that "looks runnable," which you first see the night before go-live.

Three things you already tried

Review after merge. Useful. That is not a veto; it is an after-the-fact blessing. If that DDL blows up, the record says "DBA looked."

Hand-diff before deploy. Line up the PR SQL against today's CREATE TABLE. You are still aligning statement noise: VARCHAR(64) to VARCHAR(128) fills half the screen; a missing foreign key hides on line 47. When you finish, you still do not know whether those are the three changes the last approved version actually agreed to.

Ban the Agent from the database. Correct. Credentials in .cursor/mcp.json get committed and screenshotted. After the ban the Agent does not disappear. It reads a stale @schema.sql, a permission-filtered information_schema dump, or it invents. Intent is still invisible before merge.

Each of those does half the job. Together you still get executable DDL two hours before go-live.

A live catalog does not save this half of the gate

Someone will say: wire a live-catalog MCP so column names stop hallucinating and the DDL is "more true." That half of the column problem is another article — permission-filtered information_schema is another hallucination, a 240-table dump blows context, tool lists cache until restart. Even when structure reads correctly, what the DBA needs to veto is not "does this column exist."

The gate asks: is this change the intent the team already approved? Can the statements that will run align with the last approved contract? A live catalog shows what the database looks like now. It does not show what humans agreed to. The database is current state; the contract is a promise. Two hours before go-live, lining SQL up against current state only checks whether the Agent invented against production — you still did not get a window to say no.

Structure is not semantics. status CHAR(1) is correct in the catalog; "only '1' is valid, '9' is dirty" lives in comments and review notes, not in the live DB. An Agent that writes a mechanically plausible ALTER from the catalog is the hardest to veto: every line looks familiar; together you cannot tell what it will do.

So the missing piece is not a faster SQL reader. It is an intent diff you can see before merge, plus an optional DDL draft generated from an approved version — still not executed.

Swap the gate object: intent first, DDL second

Move from "Agent dumps SQL → human signs the night before merge" to "Agent declares intent → save a named version → human diffs before merge, optionally reads a DDL draft → can still veto."

The flow:

The team maintains schema in the designer. Each change that is actually accepted saves as a named version. That projectJSON is the contract: human-reviewed, API layer strips profile.dbs credentials, Chinese names and remarks carry tribal knowledge next to the structure.
When the Agent needs a schema change, the only write path in this copy is create_version: submit a suggestion with a note. Do not treat put_project_json as a tutorial — that overwrites the workspace; API 200 is not human approval.
Before merge, the DBA opens a semantic diff against the last approved version: which table was added, which field removed, which FK moved from A to B. Not an eighty-line character diff of ALTER.
When you need a starting point for the migrator, generate a DDL draft from that approved version. The draft is marked previewOnly: true, executed: false. ERD does not execute SQL, does not connect to your database, and does not replace Atlas / Flyway / your CI.
This gate can still say no. The veto happens before intent enters main — not two hours before the release window.

One sentence vs "read SQL the night before go-live": the gate moves earlier; the veto stays; the Agent never gets production credentials. The Lead signs intent (that article stops at the Approve button). You sign "this intent may enter the merge pipeline." Neither gate is "CI was green, so a human looked." When you veto, you leave a traceable intent diff — which table, which column, which FK — not a chat message that says "don't merge tonight."

Be honest about the draft: today it is a conservative CREATE TABLE from a named version, filtered by dialect and table. It is not the ALTER that will run in production, and it is not a down migration. Lock time, backfill, and canaries stay your CI and your window. The draft lets you ask "after the contract looks like this, what does CREATE look like?" — not let an Agent click execute. Missing indexes, missing FKs, dialect type mismatches sit in warnings. You review them. The tool does not pretend it already did.

What MCP does here (you only want it at this point)

By now you might want MCP — not installed in sentence one.

Reading the contract, aligning two versions, and taking a draft that does not execute is enough to move the gate:

diff_versions: semantic diff between two named version snapshots. Tables and columns added, removed, modified; table and field remarks; conservative renameCandidates from structural fingerprints. Rename candidates need a human; they are not facts. API success is not approval.
preview_ddl: CREATE TABLE draft from one named version snapshot, MySQL / PostgreSQL / SQL Server / Oracle, optional table filter. Returns previewOnly: true, executed: false, and warnings that nothing connected and nothing ran.
create_version: the only write in this copy. The Agent reads the approved version, submits a suggestion; a human diffs in the designer.

diff_versions returns a review object, not an ALTER dump:

{
  "summary": {
    "tablesAdded": 0,
    "tablesRemoved": 0,
    "tablesChanged": 1,
    "columnsAdded": 1,
    "columnsRemoved": 0,
    "columnsModified": 2
  },
  "note": "renameCandidates are structural hints for human review, not confirmed renames. API success is not approval."
}

Three changes sit in the summary. You can point at those three and say no without hunting "which three lines are hallucinated" in eighty lines of SQL.

preview_ddl writes the boundary into the payload:

{
  "source": "saved-version-snapshot",
  "dialect": "mysql",
  "previewOnly": true,
  "executed": false,
  "warnings": [
    "Preview only: ERD Online MCP never connects to a database and never executes SQL."
  ]
}

How to read the contract: Read ER diagrams from Cursor via MCP. How to save a version and open a diff: Save a version and view the diff. When a pager asks which approved change introduced a column — that is another job, table-sliced version history. This article does not pretend that exists yet.

The CTA is not "install our MCP"

The next step is not "go install an MCP," and it is not wiring production into the IDE. It is more basic: save a named version so merge has a last approved baseline to align against.

Open the demo, change one table, save a version, change something else, save again, open the diff — in 30 seconds you see what "field added" and "FK retargeted" look like. After that, the next time an Agent drops DDL before a release window, you can reply: "Call create_version first. Send me the diff against the last approved version. DDL drafts come from the approved version. ERD does not execute."

Without a last approved version, the veto only shows up two hours before go-live. With it, you can say no before merge.

MCP #DatabaseDesign #ERD #Agent

The agent wrote the migration. Are you really going to Approve it?

erdonline — Sun, 30 Aug 2026 06:35:49 +0000

Tuesday afternoon, that Approve button

Tuesday, 3 p.m. A PR notification lands in Slack. Junior writes in the channel: "Cursor generated this migration for me — can you take a look?"

You open the diff. Eighty lines of ALTER TABLE. Add columns, change types, add indexes, attach foreign keys — every line is familiar on its own. Syntax is clean. Naming matches team conventions. Mechanically, it all looks plausible.

But together? That NOT NULL on biz_order has no default — will it pass on existing rows? How long does the type change on sys_user lock the table? Does the down migration actually restore the previous schema? The PR description says "Agent self-review: should be fine" — that is not evidence.

Reject the whole thing and you look like you are blocking the team or fighting AI. Click Approve and your name is on it. When production blows up, the postmortem asks "who approved this version?" and you say: "CI passed; it looked okay to me."

You cannot spin up a database for every PR. In the end there are only two performances: pretend to understand — comment on naming and click Approve; pretend to be strict — send it back three times for formatting, and still nobody notices the missing join table.

This failure has a name: reviewed without reviewing

This is not a moral failure of "not reading carefully enough." It has a name — reviewed without reviewing: generation speed went up; human review speed did not. The Agent spits out eighty lines of ALTER in three seconds; your brain still runs at "read SQL line by line." SQL diffs are mostly noise — VARCHAR(64) to VARCHAR(128) fills half the screen, while the change that actually blows up (missing join table, FK pointing at the wrong parent) hides in the middle and looks like any other edit.

People in the industry summarize it in one line: No human can review at this speed. That is not an insult — it is a mechanism claim. When the output is executable statements and the input is an eighty-line character diff, the Tech Lead is effectively signing blind. The moment you lose face and own the blame is the postmortem, not the Approve button on GitHub.

There is a sneakier variant: which three lines in this migration are hallucinated? Not syntax errors — semantic errors. The Agent used a stale @schema.sql and invented a join table that "should" exist. Or it set a default on del_flag that your team never uses. Every line runs; together they break a query you did not think to test.

Four things you already tried

Stricter CI. Lint migration file names, require down files, run sqlfluff. Helpful — but CI checks format and parseability, not "will this table lock for ten minutes on Tuesday peak traffic." Green does not mean "I will sign Approve."

Agent self-review. "Check this migration for risk and output a confidence score." The model politely returns "low risk" — it did not run that ALTER against your real row counts either. Self-review is tone, not acceptance.

Declarative diff tools. Prisma, Atlas, and similar tell you "what changed in the model vs last revision." Progress — the diff object is no longer raw SQL. But the declaration is still not "what will execute": the migration that lands in prod can diverge from the declaration; and field-level diffs are still noise, not "what this change means for the business."

Finer code review policy. "Migrations need two approvers." "Agents cannot push to main." Process is right; the object under review is still SQL noise. If the second approver only glances at green CI, you now have two "looked fine to me" signatures.

Live catalog and SQL diff both miss this half

Someone will say: wire the Agent to live DB so column names stop hallucinating. Job 1 already covered why — production credentials in the IDE are a red line; 240-table dumps blow context; permission-filtered schema is another hallucination. Even when structure reads correctly, that is not what the Lead needs to review.

The Lead needs to answer the product question in the meeting: "Will this schema change blow up?" — which means "relative to the last approved version, what are the semantic changes?" not eighty lines of ALTER. Live catalog MCP solves "does this column exist?" Semantics — soft delete still on this table?, is this status code still valid?, should this FK point at sys_user not biz_user? — live in notes, review records, and human-approved versions, not in information_schema.

So the trap is not "we need a better SQL linter." It is reviewing the wrong artifact: you Approve executable statements without an "approved intent" to align against.

Swap what you review: version diff, not migration diff

Our approach moves the Agent write path from "dump SQL for you to sign" to "declare intent → save as a version → human diffs in the designer."

The flow:

The team maintains schema in the designer. Each change saves as a named version — that projectJSON is the approved contract.
When the Agent needs a schema change, it does not call put_project_json to overwrite the workspace (API 200 is not human approval). It calls create_version: submit a suggested revision with a note.
The Tech Lead opens the version diff — not eighty lines of SQL, but: which table was added, which field removed, which FK moved from A to B. Column labels and notes carry tribal knowledge: next to status, "1=valid 9=dirty" is closer to what you review than CHAR(1).
Point at three changes in the diff, say "I reviewed these three," then accept — the named version you produce is what goes in the changelog and aligns with what the Agent declared.

DDL drafts can be generated from approved versions for DBA reference; ERD does not execute SQL. Landing migrations in the database is still Atlas / Flyway / your CI. The Agent gets no production credentials; the Lead does not blind-sign raw migrations.

One sentence on the difference vs "Agent writes migration, you sign SQL": API 200 is not human approval. Approval happens after you read the diff in the designer.

What MCP does here (and what it does not yet)

By now you might want MCP — not at the opening of the article.

Today the only MCP write path is create_version: the Agent reads the approved contract via list_tables / describe_table, updates the model, submits a suggestion; you diff in the designer. See Read ER diagrams from Cursor via MCP and Save a version and view the diff.

One honest gap: semantic diff_versions — ask MCP "what three semantic changes between v1.3 and v1.2?" instead of scanning the version panel by eye. That is the Job 2 build target; until the tool ships, Leads still open two versions in the designer — but the object is at least the contract, not SQL noise.

Planned optional capability: DDL draft from two contract versions as a DBA starting point — still no execution. Hard merge gates and DBA veto before main — that is another journey (Job 4). This article stops at the Lead's Approve button: you sign intent you diffed, not eighty lines the Agent spat out.

The CTA is not "install our MCP"

The next step from this article is not "go install MCP first." It is more basic: save a version and walk through diff approval once.

Open the demo, change one table, save a named version, change something else, save again, open the diff between the two — 30 seconds, no signup. If you have not walked "Agent suggests → human diffs → approve" yet, practice with your own two hand-edited versions first: what "field added" vs "FK retargeted" looks like in the diff, so when the Agent calls create_version you know where to look.

The moment you save that first named version, you have a "last approved baseline" to align against. Without it, the Agent's eighty lines are a blind sign — the Approve button is there; whether you dare click depends on whether you reviewed SQL or the contract.

MCP #DatabaseDesign #ERD #Cursor

Don't give your agent the production database

erdonline — Sat, 29 Aug 2026 15:25:04 +0000

The second you hit Enter

Friday night. You ask Cursor for a query: join orders to users, sort by last login. Three seconds later, an answer arrives with DBA-level confidence:

SELECT o.id, o.amount, u.last_login_at
FROM biz_order o
JOIN sys_user u ON u.id = o.user_id
ORDER BY u.last_login_at DESC;

Paste it into your client. Enter:

ERROR: column "last_login_at" does not exist
LINE 2: SELECT o.id, o.amount, u.last_login_at

There is no last_login_at column. There never was. The model did not know — it just decided the column "should" exist.

This failure has a name: invented column

This is not "AI is not smart enough yet." It has a name — invented column: the model fabricates a plausible column name with no factual source, then writes it into a JOIN with unshakable tone.

Invented columns are dangerous because they do not look like errors. last_login_at appears on 90% of user tables. Syntax is correct. Naming is conventional. Indentation is perfect. Mixed into ten correct JOINs, you will not catch it line by line. You find out in code review — or worse, in production logs.

Three things you already tried

A better prompt. "Do not invent column names; only use the schema I provide" — added to the system prompt. Works day one. By day three, long context and the model forgets. A prompt is a wish, not a constraint.

@schema.sql. Export DDL and drop it into context. The most honest approach today — but two holes: it goes stale (last week's export does not know this week's column), and nobody maintains it (not in any approval flow; anyone can edit it; drift from the real database goes unnoticed).

Live catalog MCP. Let the Agent query information_schema directly. Directionally correct — give the model a fact source instead of guesses. Tools like postgres-mcp and cloud vendor MCPs do solve half of "stop hallucinating column names." Worth acknowledging.

Live catalog only gets you halfway

Wire production into the IDE and you hit four walls:

Permission-filtered information_schema is another kind of hallucination. The database account you give the Agent probably cannot see every table. The "complete schema" it returns is only the slice it is allowed to see. The model will not say "I only see 60% of tables." It keeps inventing columns in the missing 40%.

A 240-table full dump blows context. Real projects are not eight-table demos. Dump everything and you either truncate or drown the three relevant tables in noise.

Production credentials in the IDE are a red line. Your .cursor/mcp.json ends up in git, screenshots, and devices you forgot you synced. Read-only is still production.

Tool-list cache refreshes only on restart. A colleague adds a column at 10 a.m.; your Agent at 3 p.m. still writes SQL from cached schema — the same stale problem as @schema.sql, just harder to spot.

And something more fundamental: structure is not semantics. information_schema tells you status is CHAR(1); it does not tell you '1' is valid and '9' is dirty data. It tells you del_flag exists; it does not tell you every query must include del_flag = '0'. Live catalogs are solving structure; semantics live in people's heads and review records — not in the database.

Swap the fact source: read the contract, not production

Our approach moves the fact source from "production database" to "approved version."

In ERD Online, schema lives in the designer. Each change saves as a named version humans can diff and roll back. That projectJSON is the contract: human-reviewed, no database passwords (profile.dbs stripped at the API layer), and naturally semantic — column labels and notes are where tribal knowledge like "del_flag = '0'" gets written down.

The Agent reads the contract, not production. Three direct consequences:

Zero credentials: only a project-level PAT in the IDE — no database accounts.
No stale drift: the contract updates with versions; the Agent reads what the team just approved.
Accountability: which version the Agent used is right there in the version id.

Progressive disclosure, not a full dump

Contracts can be large too, so how you read matters. We added two MCP tools deliberately shaped as "list first, expand on demand":

list_tables returns table name, label, and field count — eight rows for an eight-table project, 240 rows for a 240-table project, neither blows context. The Agent picks the two or three it needs, then calls describe_table for fields and FK neighborhood (who references me, whom do I reference).

When the Agent guesses a wrong table name, the response is not silence or fabrication:

{
  "found": false,
  "query": "user_id",
  "suggestions": ["sys_user", "sys_user_role"],
  "hint": "Table not in the approved contract. Retry with one of the suggestions; do not invent columns."
}

found:false plus suggestions — invented columns get blocked at the tool layer, not by "please do not hallucinate" in the prompt.

Both tools read an approved version snapshot (pass versionId to pin a revision). No SQL execution. No database connection. Same configuration path as existing tools — see Read ER diagrams from Cursor via MCP.

The CTA is not "install our MCP"

The next step from this article is not "go install an MCP first." It is more basic: save a version for your model.

Open the demo, change one table, save a named version, watch the diff — 30 seconds, no signup. The moment you save that first version, you have a contract the Agent can read and you can stand behind. MCP comes after, if you want it.

👉 Try it in 30 seconds without signing up: https://www.erdonline.com/demo?utm_source=hashnode&utm_campaign=mcp-agent&utm_content=dont-give-agent-prod-db

Open source (MIT — star / issue / PR welcome): https://github.com/erd-online/erd-online?utm_source=hashnode&utm_campaign=mcp-agent&utm_content=dont-give-agent-prod-db

MCP #DatabaseDesign #ERD #Cursor

Average position 1. Zero clicks. Eight URLs, one identity.

erdonline — Sat, 29 Aug 2026 10:32:57 +0000

Search Console told us we were ranking. In Singapore, average position 1. Across three months: 42 impressions, 0 clicks. Not a low click-through rate — none.

Twelve days and one engineering pass later, the same property read 2 clicks / 103 impressions / 1.9% CTR / average position 62.7. Inside that, two rows that shouldn't be able to coexist:

URL	Clicks / impressions	Average position
`https://www.erdonline.com/`	1 / 90	61.3
`https://www.erdonline.com/compare`	1 / 8	~2–3

One page buried on page six for the queries people actually type. Another sitting at position two for a query almost nobody types. The instinct in that moment is to write more content, because "more content" is the answer every SEO article gives. It was the wrong read, and chasing it would have cost us a month.

The real problem was that our site had one identity. It had eight marketing URLs, a sitemap, hreflang tags, and JSON-LD — and every single one of those URLs handed Google the same first byte.

The diagnosis takes one command

We build a client-rendered UmiJS app hosted on Cloudflare Pages. Before diagnosing anything clever, curl what the crawler gets:

curl -sL https://www.erdonline.com/catalog | grep -E '<title>|rel="canonical"'

The answer, for months, was the homepage's <title> and <link rel="canonical" href="https://www.erdonline.com/">. Same for /compare. Same for /en. Same for /demo. And then this one:

curl -sI https://www.erdonline.com/__seo_health_nonexistent_path__
# HTTP/2 200

A URL that has never existed, returning 200 with the homepage in the body. That is a soft 404, and once you have one, you have infinitely many. Googlebot doesn't see a site with eight pages plus some noise. It sees one page reachable at an unbounded number of addresses, which is the exact shape of a low-quality site, and it responds by picking one URL to keep and quietly discarding the rest.

Rank was never the bottleneck. Being a distinct page was.

Two platform defaults, both documented, both easy to miss

Neither cause was exotic. Both were things we had written ourselves and then stopped looking at.

A catch-all rewrite. public/_redirects contained /* /index.html 200. This is the line every SPA tutorial tells you to add so client-side routing survives a hard refresh, and it is correct for /project/1234, a page behind a login that has no business being indexed. It is destructive for /compare, a page whose entire job is to be indexed under its own title.

No top-level 404.html. Cloudflare Pages has a documented rule here that catches people: if there is no 404.html at the root of your build output, Pages assumes you are a single-page app and serves 200 + index.html for every path that doesn't match a static file. Ship a 404.html and that automatic SPA mode turns off — unmatched paths get a real HTTP 404. One file, and infinite soft 404s stop.

Three smaller footguns cost us a deploy each, and they are the kind of thing nobody writes down:

A rewrite target of /index.html doesn't work. Cloudflare 308-redirects *.html to its extension-less form, so a rewrite meant to be invisible becomes a redirect to /.
The splat in /catalog/* → / 200 matches /catalog/ with an empty segment, so the catch-all quietly shadowed the very list-page shell we had just generated. It has to be /catalog/:id.
We first sent unknown template IDs to a placeholder shell at /catalog/_item. Because that path is a directory, Cloudflare 308'd /catalog/some-bad-id onto /catalog/_item/ — we had invented a brand-new crawlable junk URL while trying to clean up crawlable junk URLs. The fix was to rewrite unknown IDs to /catalog/ (already slashed, so nothing to 308 onto) and 301 _item away.

Every one of those is a redirect rule that is almost right. Which is the point: this class of bug produces a perfectly working website for humans and an unindexable one for crawlers, and no amount of reading your React code will surface it.

Four artifacts, one source of truth

The fix was to prerender a per-path shell at build time — dist/catalog/index.html, dist/compare/index.html, dist/en/compare/index.html, and so on — each carrying its own <title>, canonical, hreflang set, and JSON-LD, then remove those exact paths from the redirect file so the static file wins.

That's the obvious half. The half worth stealing is what we did to stop it from rotting.

Adding one public route requires four artifacts to agree:

the list of URLs in sitemap.xml
the set of paths that get a prerendered shell
the Cloudflare _redirects rules for everything that doesn't
the nginx map for self-hosted Docker deployments

Four files, maintained by hand, in a repo where the person adding a route is thinking about React Router and nothing else. They will drift. Ours did.

So they all became derived values exported from one module, frontend/scripts/seo-config.mjs: SITEMAP_PATHS, PRERENDER_PAGES, CF_SPA_REDIRECT_RULES, NGINX_SPA_URI_REGEXES, plus marketingHreflang() and jsonLdForPage(). The build script consumes it and writes sitemap.xml, robots.txt, _redirects, _headers, 404.html, and every shell in one pass. Adding a route is one entry in one array. Drift between the sitemap and the redirects is no longer a mistake you can make.

That file is also where the hard-won knowledge lives, as comments next to the rules they explain — including the one that reads, in effect, do not use `/catalog/` here, we tried, here is what Cloudflare does*. Comments that record a footgun earn their keep. Comments that narrate what the next line does do not.

Two bugs that only exist in single-page apps

With the shells shipped, two failures showed up that have no equivalent on a server-rendered site.

Hydration fought the shell. /catalog/demo-authz prerendered correctly, then the client booted and CatalogLayout called usePageSeo(catalog.seo.*) unconditionally — so the detail page's title was replaced, a few hundred milliseconds later, by the list page's title. The prerender was right and the app overwrote it. If you prerender per-path metadata in a CSR app, your client-side SEO hook needs to know which page it is on, or you have built two systems that disagree about <title>. Now the list applies list metadata, and a detail page waits for its API response and writes {name} — ER diagram templates with a canonical pointing at /catalog/:id.

Every page claimed to be the app. Our JSON-LD generator was parameterizing url and nothing else, so @type stayed WebApplication everywhere. Eight distinct pages each announcing themselves as the application living at the site root — structured data actively contradicting the canonical tags we had just fixed. It's now typed per path: / is a WebApplication, the template list is a CollectionPage, an official template detail is an ItemPage, everything else is a WebPage.

The title problem was a promise problem

Position 1 with zero clicks is not a ranking failure. It is a snippet that doesn't sound like the thing the searcher wanted.

Ours was brand-first, and the searcher's job-to-be-done was not "learn about a brand." It was "draw an ER diagram, in a browser, now." The queries said so plainly: erd online, erd diagram online, make|create|draw erd online. So the <title> became job-first — Draw ER Diagram Online — Free Editor | ERD Online — and the description covers the intent cluster in one honest sentence: draw, ERD editor and maker, entity-relationship models.

Three things we deliberately did not do, now written into docs/landing.md as rules rather than left to judgment:

No "file viewer." It's a plausible, high-volume phrase. We support ERD/PdMan/DBML import; we do not ship a dedicated file viewer. Ranking for a query you can't satisfy buys one visit and one bounce.
No naming Google Draw. Our comparison page names draw.io, because we have a real technical claim there — a line in draw.io is a line, while a relationship in ERD Online carries foreign-key semantics. We won't name a product we haven't actually compared.
No stuffing the non-English queries we could see in the query report. Impressions from an audience we don't serve in their language are not a win.

The H1 stayed "Git + Figma for database design." The <title> and the H1 now disagree, on purpose. The <title> answers a query; the H1 answers "what is this, and why should I care" for someone who has already arrived. Collapsing both into keywords costs you the second job and reads like a landing page from 2011.

Make the crawler's view a test

The failure mode here is silent, so the only durable fix is an assertion. scripts/seo-index-health.mjs runs daily in CI and checks, against the live site:

Each of /, /demo, /catalog, /compare, /docs/, /docs/roadmap: HTTP 200, text/html, non-empty <title>, non-empty meta description, a canonical, and no noindex.
/robots.txt: 200, not text/html (a robots.txt served as HTML means the SPA fallback ate it), contains User-agent: *, contains an absolute Sitemap: URL, and does not contain content-signal: — that last string is how you detect that your platform's injected default robots.txt is still winning over yours.
/__seo_health_nonexistent_path__: must return 404. This is the soft-404 regression, pinned as one assertion.
/compare, /catalog, /demo, /login: must still return 200, because the obvious way to fix soft 404s is to break your real routes.
sitemap.xml: parses, has at least one <loc>, and the first 20 URLs are reachable.

At build time, yarn test:seo-static runs the same config without a full build, and the production smoke suite has a test named, verbatim, crawler first HTML uses path canonical (not homepage). The bug we shipped for months now has a name in a test file.

Two more things from the same pass, both non-obvious:

Cache headers alone did nothing. The homepage was returning CF-Cache-Status: DYNAMIC with TTFB around 1.6s (our docs site, 3.8s) while Search Console flagged impressions sliding. We set Cache-Control: public, max-age=0, s-maxage=600, must-revalidate on the HTML shells. Nothing changed — Cloudflare Pages treats text/html as dynamic by default, and you must also create a Cache Rule in the dashboard making HTML eligible for cache. That dependency is now a comment in _headers, because a header file that silently does nothing is worse than no header file.

Pick one slash form and make all four places agree. Our docs site canonical said no trailing slash, the sitemap <loc> said no trailing slash, the host 308'd to a trailing slash, and legacy redirects pointed at the non-slash form — so an old URL took a 301 and then a 308 to arrive. trailingSlash: true, redirect targets slashed, sitemap <loc> slashed, /search and blog tag/archive pages dropped from the sitemap. One hop.

What we stopped doing

Clicking "Request indexing." We tried it on /catalog twice and got Search Console's reCAPTCHA error both times; nothing entered the queue. Manual submission is a nudge, not a mechanism, and treating it as progress hides the fact that your artifacts are still wrong. Fix the artifact, submit the sitemap, then wait.

We also decided, in advance, what would make us change strategy. Our locale routing ADR ships English marketing pages as CSR with a sitemap and hreflang, and states the trigger explicitly: if /en is not indexed 90 days after launch, we build static export for the marketing routes. Writing the trigger down before you need it is what stops "should we go SSR?" from being re-litigated every two weeks on vibes.

The same ADR is worth reading for what it refused to do. Full-site /en/* routing would have touched 60 route entries, 76 history.push call sites across 39 files, 236 page.goto calls in the E2E suite, 16 backend files containing frontend URLs, and the immutable /s/:token share links already pasted into other people's chat logs. The pages that would have gained from it — /project/**, /design/**, /home — are all behind a login and have no search value whatsoever. Marketing pages got the prefix. Nothing else did. Internal link points touched: about 21.

The scoreboard, honestly

As of today: /catalog, /compare, and /en/compare are indexed. /en/catalog is "discovered — currently not indexed." The docs site's English sitemap was accepted and 66 pages were discovered. Total organic clicks over three months: 2.

This is not a traffic case study. Indexing moves on a timescale of weeks, and it would be dishonest to attach a hockey stick to a twelve-day engineering pass. What we can report is that the crawler's view of the site is now correct, asserted daily, and cheap to extend — which is the part that had to be true before any content investment could compound.

The checklist

If you run a client-rendered site, these are worth thirty minutes:

curl -sL <your-non-homepage-url> | grep -E '<title>|canonical'. If you see your homepage, stop reading and fix that.
curl -sI <your-domain>/__definitely_not_a_real_path__. If it's 200, you have unbounded soft 404s. On Cloudflare Pages, ship a root 404.html.
Delete the catch-all rewrite. Enumerate the SPA paths that genuinely need a 200, and let everything else 404.
Make sitemap, prerendered shells, host rewrites, and self-host rewrites derive from one module. Adding a route should be one line.
Check that hydration isn't overwriting per-path metadata your build just wrote.
Check @type in your JSON-LD is actually per-page, not the homepage type with a swapped url.
Pick one trailing-slash form. Canonical, sitemap <loc>, host redirect, and legacy redirects must all agree.
Turn every one of the above into a daily assertion against production. This bug class is silent by construction.

What we're building

ERD Online is an open-source (MIT) database design tool: Git + Figma for database design. Versions and collaboration are the moat, and the projectJSON format is open so humans and AI agents read and write the same source of truth — an agent can call create_version through MCP, and a human still reviews the diff in the designer. It is not ChatSQL; it will not invent a diagram from a sentence.

Open a real ER diagram, read-only, no signup: https://www.erdonline.com/demo

Source, issues, and the SEO scripts described above: https://github.com/erdonline/erdonline

The config module is frontend/scripts/seo-config.mjs, the health check is scripts/seo-index-health.mjs. Both are short. Steal them.

How to let AI agents manage your database schema (with MCP)

erdonline — Sat, 29 Aug 2026 06:07:07 +0000

AI agents are becoming first-class citizens in developer workflows. They can read code, run tests, and deploy apps. But one thing they struggle with is understanding database schemas.

Database design tools haven't changed in 20 years. You either use a heavyweight desktop app (Navicat, PDManer) or a pretty but closed web app (dbdiagram). Neither supports versioning, real-time collaboration, or AI agent integration.

I built ERD Online to solve this. It's an open-source database design tool that combines Git-like versioning with Figma-like collaboration, plus MCP integration for AI agents.

In this article, I'll show you how to let Cursor, Claude, or Cline read and write your database schema through MCP, while you keep full control.

Database schema changes are hard to track:

Who changed what?
When did they change it?
Why did they change it?
How do I rollback?

And now with AI agents, there's a new problem: how do you let an AI agent suggest schema changes without giving it a black box that generates random ER diagrams?

The wrong approach: ask AI to "generate an ER diagram for an e-commerce app." You get a diagram, but it has no connection to your actual project, no versioning, and no approval flow.

The right approach: let the AI agent read your existing schema, suggest changes, and submit them as a version that you review and approve.

That's what ERD Online + MCP does.

MCP (Model Context Protocol) is a protocol for AI agents to interact with external tools. Think of it as a USB-C port for AI applications. It standardizes how agents discover and call tools.

MCP has three main primitives:

Tools: Functions the AI can call (like list_projects or create_version)
Resources: Data the AI can read (like project.json)
Prompts: Pre-defined templates for common tasks

ERD Online exposes MCP tools that let AI agents:

list_projects: List all your ERD projects
get_project: Get a project's projectJSON
create_version: Suggest a new version of your schema

The key boundary: AI agents read/write the same projectJSON the human designer uses. They don't generate ER diagrams from a sentence. You stay in control.

Step 1: Mint a PAT in ERD Online

Sign in to ERD Online and go to Account Settings → Personal Access Tokens. Create a new token (read-only is enough to start).

Step 2: Add MCP config to Cursor

Open ~/.cursor/mcp.json and add:

1. AI agents become useful, not dangerous

By giving AI agents structured access to your schema, they can make useful suggestions. But because they go through create_version and you review the diff, they can't silently break your database.

2. Versioning becomes the source of truth

Every AI-suggested change creates a version. You can see exactly what changed, when, and why. This is essential for database schema management.

3. Collaboration improves

Multiple people (and agents) can work on the same schema. Changes are merged, versioned, and reviewed.

4. No vendor lock-in

projectJSON is an open format. You can export your schema, self-host ERD Online, or build your own tools on top of it.

ERD Online

Live demo (no signup): https://www.erdonline.com/demo
GitHub: https://github.com/erdonline/erdonline
MCP docs: https://doc.erdonline.com/docs/guide/api-and-mcp/
Cursor bridge: https://www.erdonline.com/cursor-mcp/

What would you build?

I'd love to hear what AI + database schema workflows you'd want. Drop a comment or open an issue on GitHub.