d1 or neon behind a worker for 30 req/s and about 2 gb of data D1

It comes down to where your reads have to travel, and both options have a version of that problem.

D1: 2 GB is well inside the limit, and 30 req/s of indexed reads is not a challenging number. The catch is that writes go to a primary, so a user far from it pays the round trip on anything that writes, and read replication is what you reach for to keep reads local. With 1% writes that trade looks good for you.

Neon from a Worker: use the serverless HTTP driver, not a TCP pool. There is no connection to keep warm over HTTP, which is the only reason this is viable from an isolate at all. What you are paying instead is a full round trip to whatever region your Neon project lives in, on every query. If the Worker runs in Sydney and Neon is in Virginia, that is 200ms+ before the query even starts, and your three-join dashboard page issuing four queries in sequence is now a second of pure network.

Decision rule I would use: if you want Postgres features you can name — real window functions, extensions, pgvector later — take Neon and stop pretending the Worker's location matters, put your logic where the data is. If your queries are boring and latency is the product, take D1.

Two developers is the constraint doing the most work in this question.

D1 gives you no connection management, no second billing relationship, no separate dashboard, and migrations through the CLI you already have open. Neon gives you the whole Postgres ecosystem and every tool you already know how to debug.

Pick which class of problem you would rather own at 11pm.

The thing I would actually go and look at is your joins. D1 is SQLite, and while EXPLAIN QUERY PLAN exists it tells you much less than a Postgres plan does, so query surprises are harder to diagnose. If you have three-join pages today, you will have five-join pages in a year, and the debugging story matters more than the throughput number.

We run about 2.4 GB on D1 at peaks near 40 req/s. Simple indexed read from a colocated Worker is single-digit milliseconds at p50 — our own timing, not a marketing number. The pain has been ergonomics rather than performance: seeding a realistic local database is awkward and I miss having a real psql session more than I expected to.

D1 caps out well below 2 GB per database, so this is already decided for you.