Data

Last updated 10 October 2026

One database, many views#

Everything GPU Ninja publishes, from the website and the API to the MCP tools, the desktop app and the daily digest, is built from one database, GPUDB. It is a SQLite database kept as a reviewable text dump in GPU Ninja's repository, and every change to it arrives as a reviewed pull request. Nothing queries it live: each deploy turns it into static pages and JSON files.

How the data is gathered and checked is on Data provenance. This page explains what the data means.

The collections#

GPU Ninja models the GPU market as linked collections rather than one flat list of cards, because the useful questions ("will this fit my case?", "can this run that model?") span several kinds of thing.

Collection	What a record is
Chips	A GPU processor as its designer specifies it: architecture, die, core counts, memory bus and bandwidth, reference clocks and TDP, peak throughput at each precision, host interface (PCIe generation and lanes), launch price. One chip has many boards
Boards	A graphics card you can buy, built on a chip by a vendor: VRAM fitted, factory clocks, dimensions, power connectors, cooler. Price and stock attach here
Chassis	A case, rack server or eGPU enclosure, with its GPU length clearance, slot count, expansion-slot positions, vertical GPU mount, and any bundled power supply or riser
Models	An AI model: publisher, parameter count (and active parameters for a mixture-of-experts model), quantisation, minimum VRAM, context length, architecture (layers, hidden size, key-value heads, head dimension), modality, licence
Platforms	The host and software a benchmark was run on: CPU, chipset, PCIe generation, RAM, OS, driver, framework and version
Benchmarks	The definition of a test (suite, workload, metric, unit, whether higher is better, methodology) and its results
Motherboards	A motherboard: its CPU socket, form factor and PCIe slots, each slot with its position, physical and electrical lane width and PCIe generation
Risers	A PCIe riser cable or vertical-mount kit: cable length, PCIe generation and lanes
Sockets	A CPU socket type, such as AM5: vendor and market segment. A reference value, not a product, listing the motherboards built for it

Beside these sit offers (one merchant's current price and stock for a board, chassis, platform, motherboard or riser), benchmark results (a benchmark run on a board or chip, optionally with a model, on a platform), and fit overrides (the rare cases where a card's fit in a case isn't what the dimensions say, each with a note explaining why).

Chips, boards, chassis and models have web pages and .txt companions. Platforms and benchmarks are available through the API only, and so are motherboards, risers and sockets, which the Solution Builder reads: they have no web page and no .txt companion. A benchmark number always names its platform, because a result without a pinned driver, framework and host isn't comparable.

Active, discontinued and frozen#

Chips, boards, chassis, motherboards and risers have a status: active for a current product, or discontinued for one that has reached end of life.

When a record is discontinued it becomes a frozen snapshot; a motherboard is frozen together with its PCIe slots. Its specs, its last recorded offers and its benchmark results are preserved exactly as they were, and future updates never touch them. History survives because nothing is allowed to rewrite it. In practice:

Its page (if it has one) and API documents stay published at the same URLs, marked discontinued with the date it was discontinued ("date not recorded" if the source didn't give one). The page carries a banner saying it is a preserved snapshot.
Its prices are shown as "Last recorded prices", with each offer exactly as last recorded. In the API a discontinued card or case counts as not in stock (inStock: false) with no current lowest price (lowestPriceUsd: null). Motherboards and risers never show a derived price.
It is still checked against cases and AI models added later, so you can ask whether an old card fits a new case.
Search, the buyer's guide and the MCP tools leave discontinued hardware out by default, and each lets you include it.
A frozen record can only be changed by an explicit correction: a reviewed file naming the record, every field's old and new values, the reason, and usually a source. Corrections are kept permanently as an audit trail. Setting a discontinued record back to active also takes a correction. A frozen record can never be deleted.
Price history is never rewritten, even by a correction. A wrong historical price stays in the history, and the fix is recorded as a newer value.

Models, platforms, benchmarks and sockets have no status: they are never discontinued and never freeze.

Provenance: where each value came from#

Provenance is recorded per field, not per record. Each specification value, and each offer's price and stock, has its own record of:

the source URL it was taken from;
when it was retrieved;
when a source last verified it;
the research run that produced it, if it came from the daily automated run rather than a maintainer;
its verification status.

Status	Meaning
Verified	The value was found on its cited source page
Unverified	The value is cited, but its source couldn't be fetched or didn't show it. It was kept and flagged for review
Conflicting sources	Sources disagreed, and this value was chosen by the conflict rule: a verified value beats an unverified one, then the manufacturer's or merchant's own page wins, then the most recent retrieval
Confirmed by a maintainer	Entered or confirmed by a maintainer by hand

On the website, each specification row has a "Source" disclosure showing these details, and every page ends with a list of its sources. In the API, they are in each entity's provenance map; see Collections and entities. Offers and benchmark results carry their own source link.

Freshness#

A single "last updated" date per record would make old specs look fresh and fresh prices look stale, so GPU Ninja stores and publishes absolute timestamps for each value and lets you judge age when you look.

Timestamps are UTC, to the second, such as 2026-10-04T06:12:00Z. Relative ages ("3 days ago") are worked out in your browser or app at the moment of viewing, never baked into a page.
Pages show freshness lines: card and case pages show when their specs were last verified and when their prices were checked; chip and AI model pages, which carry no offers, show the specs line only. On the website these are colour-coded: prices count as ageing after 3 days and stale after 14, specs as ageing after 180 days and stale after a year. Frozen records are shown as frozen instead.
Every API file has an asOf, the latest time any value in it was retrieved or verified. It is never the build time, so even a cached copy tells you how old its data is. It is null when nothing in the file has a recorded time. In the changes feed it is the time of the latest merge instead.
An offer's retrieved time moves only when its price or stock changes. When a merchant listing is checked and nothing has changed, the check is recorded as a new verification rather than as a new price.

Data reaches the site after a pull request is reviewed and merged, and API responses are cached for up to five minutes after that.

Prices and money#

Stored in minor units. GPUDB stores every price as a whole number of the currency's smallest unit, such as cents, together with its ISO 4217 currency code. A US price of $1,949.00 is stored as 194900. Launch prices (MSRP) are stored in US cents, because they are announced in dollars. Binary floating point never touches a stored price.
Published in major units. The API converts on the way out: an offer's price is a decimal amount in its own currency, such as 1949 or 1999.99, and lowestPriceUsd and launchMsrpUsd are decimal US dollars.
Supported currencies are USD, EUR, GBP, CAD and AUD (two decimal places) and JPY (none).
The lowest price is US dollars only. A card's or case's lowest price is the cheapest in-stock US dollar offer, or the cheapest US dollar offer if none is in stock. Offers in other currencies are listed with the product but never converted.
Plain listing links. Offers link straight to the merchant's listing. There are no affiliate links, and the validation check rejects affiliate markers in a listing URL.
Price history. Every change in an offer's price or stock is recorded internally as it happens. History isn't published through the API yet.

Measurements and units#

Lengths are in millimetres to one decimal place, slot widths in expansion slots to two decimal places (for example 3.5 or 3.15), power in watts, memory in gigabytes (an AI model's minimum VRAM to two decimal places) and clocks in megahertz. Values are stored at that precision, so fit and can-run checks never round them. A case's GPU length and slot count are its clearances, which is what fit is checked against. Memory bandwidth is in decimal gigabytes per second, and peak throughput in teraflops (TOPS for 8-bit integers); a precision a chip has no hardware support for is empty. PCIe generations are whole numbers, and lane widths are 1, 4, 8 or 16. A motherboard's slot positions count expansion-slot positions from the top, starting at 1. Unknown values are left empty and shown as "Not recorded"; they are never guessed or shown as zero.

Slugs and renames#

Every record has a slug, such as asus-rog-strix-4090, which forms its URLs. Slugs don't change unless a rename is recorded, and every recorded rename permanently redirects the old URLs, page, .txt and API alike, to the new ones. Renames are permanent in both directions: once a slug has been renamed away, it is never used again for that kind of record, so an old link can't start pointing at something else.

Reporting an error#

If a value on GPU Ninja is wrong, tell us through the channels on Support, or email support@gpuninja.com. Include:

the page or API URL;
the field that is wrong and the correct value;
a link to a source that shows the correct value, ideally the manufacturer's or merchant's own page.

A maintainer checks the source and fixes the value in a pull request. A fix to a frozen record goes through a correction, as described above. Once merged and deployed, the fix appears on the site and in the API, and in the changes feed with the operation corrected. The daily digest mentions a correction when it fixes something an earlier digest reported.