Databases in this space are not competing versions of the same list. They are four different kinds of record, built from different sources for different purposes, and each is authoritative for a narrow set of fields and unreliable outside it.
The practical skill is not picking one site. It is knowing which category you are looking at, so you know which of its fields to believe. A storefront knows what it sells and nothing else. A community database knows more titles and gets more of them wrong. Neither is lying to you; they were built to answer different questions.
What are the four categories of database?
The four are: storefront catalogues, community metadata databases, performer-centric indexes, and image or face indexes. They differ in where their data comes from, which determines everything about their failure modes.
| Category | Data source | Best at | Known weakness |
|---|---|---|---|
| Storefront catalogue | The seller's own product records | Canonical IDs, official titles, cover art, what is currently purchasable | Only covers what that seller carries; withdrawn titles may vanish entirely |
| Community metadata database | Crowd-submitted entries, often scraped then hand-corrected | Breadth across studios and eras, including out-of-print material | Uneven accuracy, stale entries, inconsistent field definitions between contributors |
| Performer-centric index | Aggregated filmographies keyed to a person | Tracking one person's work across studios and over time | Breaks on stage-name changes; early or uncredited work is routinely missing |
| Image / face index | Cover images and stills, matched by visual similarity | Finding a person when you have a picture and no text at all | Only returns what was indexed; cannot tell you a title directly, only a person |
Each row's weakness is a direct consequence of its source. That is why no amount of effort makes a storefront cover out-of-print titles, and why no community database will ever be as internally consistent as a seller's product table.
When is a storefront catalogue the right thing to consult?
Consult a storefront when you need the canonical form of a record: the exact ID, the official title as the distributor writes it, the cover, and whether the title is currently available.
Storefront data is a byproduct of commerce, which makes it unusually reliable within its scope: the seller has a direct operational reason to keep IDs, titles and availability correct, because those fields drive its own search and fulfilment. Nobody has that incentive for a title they stopped selling years ago, which is precisely where storefronts go blank.
The mistake is treating a storefront as a census. Absence from a storefront means "not sold here", never "does not exist". If you are trying to establish whether something was ever released, a storefront is the wrong instrument.
Storefront data is also the most machine-readable data in this space, which is
worth knowing if you are building anything. FANZA's operator publishes a product
API at api.dmm.com/affiliate/v3/ with separate endpoints for products,
performers, makers, series, genres and catalogue floors, returning content IDs,
titles, dates and image URLs; it requires an API ID and an affiliate ID, so it is
gated behind an affiliate account rather than open (confirmed against DMM.com
Labo's own Go SDK, pkg.go.dev/github.com/dmmcomlabo/dmm-go-sdk/api, checked
2026-08-03). That is the pattern across the market: the catalogue is available in
bulk, but as an affiliate feed, with the commercial strings that implies.
When should you trust a community database instead?
Trust a community database for existence and breadth — establishing that a title or a performer exists, and finding material no longer sold anywhere.
That is genuinely valuable, and no commercial source replicates it. The cost is that field definitions drift between contributors. "Release date" may mean the announcement, the digital release, or the physical one. Credits may be copied from a cover, from a listing, or from another database that copied them from somewhere else. Errors propagate because databases scrape one another, which is why the same wrong birth year can appear on four sites and look like corroboration.
Treat agreement between community databases as weak evidence, not strong. Two sites agreeing may mean two independent records — or one record copied twice.
What do performer-centric indexes do that the others don't?
Performer indexes are keyed to a person rather than a product, which is the only structure that can follow a career across studios.
That is their real function. A storefront organises by what it sells; a performer index organises by who is in it. If you want to know what someone worked on before and after a studio change, only the person-keyed structure answers that in one lookup.
Their characteristic failure is the name change. Stage names change between agencies, between studios, and sometimes between a debut and a relaunch, and the same person then becomes two entries with two partial filmographies. Nothing in a text-based database detects this automatically — the two records share no field.
That is also why a filmography should be read as a lower bound. It is a list of what this index knows was credited to this name, not a list of what the person made.
Where does an image or face index fit in?
An image index answers the one question the others structurally cannot: who is this, when all you have is a picture.
Every text database requires you to already know a name, an ID or a title. If you have a frame from a video and no text at all, they have no entry point. Face matching inverts that: it detects the face, encodes it as a vector, and compares it against faces already indexed, returning people rather than titles.
Our own index holds 241,792 faces across 2,333 named performers, drawn from covers and stills across 106 sites (our index, 2026-08 snapshot).
The boundary matters more than the number. Coverage is not evenly spread: of the 2,333 named performers, 2,246 have their representative image sourced from a single site. That is a substantial skew, and it means a performer who never appeared on our dominant source is far less likely to be found — while the tool will still return a ranked list of near-misses. Any image index has this shape of limitation; the useful ones tell you about it.
An image index also does not give you a title. It gives you a person, and the title comes from a second step — narrowing that person's known work by scene details. Face search and filmography databases are complements, not substitutes.
How can you tell whether a single entry is trustworthy?
Judge the entry, not the site. Four signals separate a record that was checked from one that was copied:
- Does it cite a source ID? An entry that carries the distributor's own product code can be traced back. One that carries only a title cannot.
- Does it distinguish alias from current stage name? A database that models aliases explicitly has thought about name changes. One with a single flat name field will silently split careers in two.
- Is the record dated? An entry with no "last updated" cannot be distinguished from an entry abandoned in 2015.
- Are empty fields empty, or filled with plausible junk? Placeholder values — round-number measurements, default birth dates — are a strong signal that the field was never verified. A blank field is more honest than a guessed one.
Applied consistently, these four questions do more for accuracy than choosing a "best" site ever will, because they let you grade individual records instead of trusting a source wholesale.
Related questions
- Which platform has the best search?
- FANZA or MGS: which suits how you watch?
- Where can you watch JAV legally?
- What is FANZA, and how does it work?
The sources we index, and what each contributes, are listed on our sites page.