01Source research
Primary sources stay attached.
Research agents turn source material into structured records while keeping the provenance trail visible.
Showcase · DBAI product
A database-backed site that does not read the database.
AIDB.digital is DBAI's own product, not a client engagement — which is why it is here rather than in the case studies.
It calls itself the IMDb of AI: every company, model, product and investor, and the people who move between them, cross-linked and cited. Nobody types the data in — every profile is written and rewritten by Claude research agents against primary sources. What follows is the engineering overview, including the compute bill that forced the architecture into the shape it now has.
- Property
- AIDB.digital — a DBAI product, built and operated in-house
- Role
- Design, build, data model, agent design, and ongoing operation
- Shape
- Read-mostly: roughly 1,900 crawlable entity pages against a handful of writes a day
- Status
- Live and publicly readable, with no sign-in for the index
AIDB system study · AI-generated
Research becomes a connected index.
The index
What it holds, and what it costs to serve.
The first two are the site's own live counters. The second two are properties of how it is served — and the fourth one is the whole argument of this page.
- companies in the index
960
companies in the index
- people with cross-linked profiles
501
people with cross-linked profiles
- pages prerendered at deploy
6,686
pages prerendered at deploy
- database reads on a cache hit
0
database reads on a cache hit
01 · What is in the index
The index, by entity.
Every figure below is read live from Postgres at render time. The site's own copy is generated from these counts rather than typed in, so the number in a sentence cannot drift from the number in the database.
| Entity | Records | Notes |
|---|---|---|
| Companies | 960 | 28 deep profiles, 932 master-list entries |
| Open roles | 4,761 | Synced daily from company boards |
| People | 501 | Cross-linked filmographies |
| Positions | 620 | The person-to-company edge; powers talent flow |
| Briefs | 303 | Daily newsroom, five per run |
| Tools | 100 | Re-rated weekly |
| Models | 86 | Linked to their originating lab |
| Products | 41 | Shipping surfaces per company |
| Citations | 338 | Source of record for factual claims |
| Funding rounds | 27 | Valuation and investor edges |
| Categories | 21 | Sortable leaderboards |
| Investors | 19 | Portfolio views |
The interesting table is not companies — it is positions. Because a position carries a person, a company and a time range, the same 620 rows that render a filmography also render the talent-flow graph: who left which lab for which, and when. One table, two products, no second copy of the truth.
02 · How records are written
Nobody types the data in.
Every profile is produced by a research agent and re-produced on a schedule. The pipeline is identical whether a cron triggers it or an administrator presses Refresh on a profile — which is what makes the scheduled path testable by hand.
- 01
Research
Claude Sonnet 4.6 with live web search re-researches the entity against primary and major secondary sources.
- 02
Parse strictly
The run must return JSON matching the entity schema. A malformed response fails the run rather than writing a partial record — the failure mode is a missing update, never a corrupted one.
- 03
Label confidence
Every number lands as reported or as estimated. The distinction is stored rather than editorial, and it renders on the profile, so a reader is never left to guess which one they are looking at.
- 04
Store citations
Claims are written to a citations table with their domain and date, so any figure on the site can be checked against the source it came from.
- 05
Publish and invalidate
The run is recorded in an admin-only changelog, then revalidateTag() drops the cached data and rebuilds only the pages that showed it.
Freshness is visible
Each profile carries a badge: green under thirty days, amber under ninety, red beyond that. Staleness is shown rather than hidden, so the index does not quietly rot while looking maintained.
Two models, chosen by job
Claude Sonnet 4.6 does the deep research. Claude Haiku 4.5 handles the high-volume work — the newsroom, tool ratings, job classification and the reader-facing chat. A tier per job rather than one model used for everything.
| Job | Cadence | Writes |
|---|---|---|
| Newsroom | Daily · 13:00 UTC | Five briefs, grounded in a stored source set |
| Job sync | Daily · 06:30 UTC | Refreshes open roles from company boards |
| Job agent | Weekly · Wed 07:30 | Classifies and enriches new postings |
| Tool ratings | Weekly · Mon 14:00 | Re-rates the hundred-tool catalog |
03 · Serving it
The rendering strategy follows the shape of the traffic.
A read-mostly index with roughly 1,900 crawlable entity pages and a handful of writes a day should not be re-rendering per request. Each decision below follows from that shape rather than from a default.
Prerendered, not revalidated on a clock
All 6,686 pages are built at deploy with revalidate = false. Nothing expires on a timer; pages rebuild only when a write says they should.
Invalidated on write
The agents and the crons call revalidatePath() and revalidateTag() together, dropping the rendered page and the cached query behind it in one step rather than leaving one of the two stale.
Cached at the query layer too
Reads are wrapped in unstable_cache with entity tags, so even a page-cache miss re-renders from cached rows instead of reaching Postgres.
Personalisation stays client-side
The administrator check runs in the browser against a cookie-only endpoint. Reading it on the server would make every route dynamic — one cookies() call in a root layout is enough to do that.
04 · The bill that made this necessary
The database was awake almost every hour it was billed for.
This section is on the site because it is the useful half. Neon bills compute by wake time rather than by query count, and for one billing period this property never once reached its five-minute idle timer.
- Measured
- 620 of the 621 hours in the period awake — 99.8%, with no suspend events logged across five straight days
- Cause
- Roughly 1,900 crawlable pages, each rendering per request
The root cause was not traffic volume. A cookies() read in the root layout forced every route to render dynamically, which quietly turned every per-page caching declaration in the codebase into a placebo. Ordinary crawler traffic across the sitemap then meant fresh SQL every few seconds, around the clock, for a site almost nobody was writing to.
The counter-intuitive part is that lengthening the cache window does not fix it. At 1,900 pages, even a twenty-four-hour window still means a regeneration roughly every forty-five seconds once a crawler is sweeping — comfortably enough to hold the compute open indefinitely. The fix has to remove the timer, not extend it.
What actually changed
Prerender the entity pages, and let writes rather than clocks invalidate them.
Move view counting out of the render path — it was a database write on every crawler visit.
Cache the query layer, so that a page-cache miss re-renders without reaching Postgres.
Widen anything sitting exactly on the five-minute suspend boundary.
Disallow /api/ and faceted URLs in robots.txt — the routes that genuinely cannot be static should not be crawled.
The content surface now serves entirely from cache: every entity page returns a cache hit, with no function invocation and no database read behind it.
05 · Stack
What it is built on.
Nothing exotic, and that is deliberate. The interesting engineering is in the agents and the data model; the delivery layer is the boring, well-understood one, which is what makes it cheap to keep running.
| Layer | Choice | Why |
|---|---|---|
| Framework | Next.js 16.2 · React 19 | App Router; static rendering is the point |
| Database | Neon Postgres | Scale-to-zero suits a read-mostly index |
| Access | Drizzle · neon-http | Stateless one-shot reads, no idle pool |
| Agents | Anthropic SDK | Sonnet for research, Haiku for volume |
| Hosting | Vercel | Edge cache plus scheduled agent runs |
Why it is on this site
The rules DBAI works to, with the receipts attached.
Every DBAI build runs under a written compute standard: no dynamic rendering on public content routes, no per-view database writes, freshness from on-write invalidation rather than short cache windows, and nothing in a root layout that opts the whole tree into rendering per request. Section 04 above is where that standard came from. It is not a principle this company adopted because it sounded prudent — it is a bill it paid on its own property, diagnosed, and then wrote down.
That is the reason this is worth showing rather than describing. A prospect can read the failure, the measurement, the misdiagnosis that would not have worked, and the fix, on the property where it happened — and then check that the same rules are visibly holding on the site they are reading it on.
The property
Open it and check the work.
Everything above is readable without an account. The methodology page states the inclusion bar and the refresh rules in the site's own words, and the citation policy states what it does with sources.
Visit aidb.digital (opens in a new tab)
AIDB.digital carries the reciprocal credit in its own footer: powered by DBAI.Agency (opens in a new tab)
Bring us the domain where being wrong is expensive.
We will show you what the decision rules, the evidence trail and the refresh schedule would look like as a running system.
Book a Discovery Call