# Investigation — Vercel Hobby could not carry the CMS

A flowingkhaos fix · monitoring · updated 18 Sept 2026
Source: https://flowingkhaos.com/fixes/vercel-hobby-could-not-carry-the-cms/investigation

## Step 1 — the first plan was aimed at the wrong app

The first plan was a rewrite of clevrstart, our most visible site. It looked like the obvious
suspect. It was scoped at **40 to 80 hours** (estimate).

Then we read the Vercel dashboard **per project** (measured, 2026-08-30, 30-day Fluid Active CPU):

| Project | Share of the account's CPU |
|---|---|
| flowingkhaos (old app) | **32.5%** |
| cms | **22.2%** |
| clevrstart | 7.9% |
| everything else | the rest |

The rewrite would have freed about **one fourteenth** of the problem. The two apps that mattered
were somewhere else. Worse, the mechanism the plan blamed did not exist: clevrstart was already
revalidated by webhook, not by polling.

> **Attribution is the first measurement.** Before per-route tuning, before any rewrite: which
> project is spending?

## Step 2 — what each heavy app was actually worth

**The old flowingkhaos app** held a third of the account's compute for **4 users, 1 gated page and
no revenue** (measured, 2026-09-05). No tuning makes that ratio good. It was paused, and the
property was re-planned as a static site.

**The CMS** is worth a lot: every site reads from it. So it could not be paused. It had to move.

## Step 3 — could the database move with it?

The obvious plan was to move the CMS *and* its data into one Railway project. We checked before we
decided. One query lists every foreign key that crosses from one schema into another:

```sql
select tn.nspname, tc.relname, fn.nspname, fc.relname, con.conname
from pg_constraint con
join pg_class tc on tc.oid = con.conrelid join pg_namespace tn on tn.oid = tc.relnamespace
join pg_class fc on fc.oid = con.confrelid join pg_namespace fn on fn.oid = fc.relnamespace
where con.contype = 'f' and tn.nspname <> fn.nspname;
```

It returned **25 foreign keys** pointing into `cms.users`: 22 from `ccc`, 3 from `scheduling`
(measured, 2026-09-11). Postgres cannot keep a foreign key across two servers. Moving `cms` alone
meant dropping all 25 guarantees. Moving the whole instance meant migrating the fleet.

And there was no money to save on the data. Neon was on its **Free** plan, holding **80 MB** of a
512 MB limit (measured). It cost **0 USD**. A Postgres container on Railway would cost about
**3–6 USD a month** (estimate, from published rates) and would lose Neon's branching and
point-in-time restore.

**Decision:** move the compute, keep the data. The 22.2% was compute. Moving compute alone
reclaims all of it.