Here's the good news for anyone building on biomedical data: the best sources in the world are free. PubMed, ClinicalTrials.gov, the FDA's databases, the patent record — all public, all enormous.
Here's the bad news: "free" and "usable" are different words. Each of these sources has a specific way of eating your week — an identifier that doesn't join to anything, a format from a previous decade, a freshness that quietly lags reality. This is a field guide. For each major source: what it is, how big, and the exact trap.
Tier 1 — Looks easy, has a sting
PubMed — 40M+ citations
The literature backbone: over 40 million citations and abstracts, with a clean E-utilities API. [1] The trap: search relevance. The default query expansion explodes common terms via MeSH synonyms, so a naive multi-word search returns noise; you need properly structured Boolean queries to get signal. Author disambiguation and affiliation parsing are their own projects. Easy to fetch, hard to make precise.
ClinicalTrials.gov — 590K+ studies
Over 590,000 registered studies with a modern v2 API. [2] The trap: the fields you most want — intervention names, sponsors, conditions — are free text. The same drug appears under brand, generic, and code names; the same sponsor under a dozen spellings and post-merger identities. Pulling the data is a morning. Resolving "which trials are actually the same drug or sponsor" is the real work.
Tier 2 — Born as documents, not data
openFDA drug labels — 259K+ records
openFDA exposes over 259,000 structured drug-label records and 20M+ adverse-event reports through a friendly JSON API. [3] The trap: those labels originate as SPL XML, and the "structured" fields are long prose blobs (indications, warnings) that still need parsing to be queryable. Adverse-event drug names are messy free text. It's a great API sitting on top of fundamentally document-shaped data.
FDA Orange Book & NDC Directory
The Orange Book links drugs to patents and exclusivity; the NDC Directory enumerates marketed products. The trap: identifier joins. Application numbers, product numbers, and 11-digit NDCs printed in three different 10-digit segment formats must be zero-padded correctly before anything joins [4] — get the padding wrong and the same drug silently splits in two. The ingredient names don't cleanly match the names used anywhere else, either.
Tier 3 — Big, and identity is the whole problem
GUDID (medical devices) — 5.1M+ records
The FDA's device-identification database held over 5.1 million device-identifier records in its mid-2026 release. [5] The trap: a new version or pack size legally gets a new identifier, the EU's EUDAMED is a separate system with no crosswalk, and relabelers assign their own IDs — so one physical device scatters across many records. We dug into this dirty-identity problem separately; for now, just know that counting distinct devices here is an entity-resolution task.
ChEMBL — ~2.9M compounds
A superb hand-curated bioactivity database: ChEMBL release 36 catalogs about 2.88 million compounds. [6] The trap: cross-referencing. A molecule's ChEMBL ID, your internal code, the brand name, CAS, and the salt form are all different — and the salt vs parent distinction trips up nearly everyone. Reconciling ChEMBL to your other sources is itself a project.
Tier 4 — Bring a tolerance for pain
USPTO patents — 12M+ granted
More than 12 million patents granted, ~327,000 added a year. [7] The trap: bulk XML across changing schemas and decades, assignee names that never normalize (the same company under dozens of spellings and subsidiaries), and the actual signal — claims, chemistry, the drug a patent actually covers — buried in text that requires real extraction. Nothing about this is a quick join.
The pattern under the ranking
Notice what makes a source "hard." It's almost never the download. The friendly APIs (openFDA, ClinicalTrials.gov v2) lull you into thinking the job is done when you have JSON. The difficulty is everything after the fetch: parsing document-shaped fields into structure, and — over and over — resolving that two differently-named records are the same entity. None of these sources share identifiers with each other, so the moment you want to combine two of them, you're doing entity resolution whether you planned to or not. The FAIR data principles named this years ago: data "usually need to be integrated with other data," and these sources are built to resist exactly that. [8]
Which is why the honest estimate for "integrate source X" is rarely the afternoon people budget. The fetch is the afternoon. The normalization and entity resolution are the quarter — and they're the same quarter whether you're building one pipeline or, eventually, a whole data stack.
Which of these sources has quietly eaten the most of your team's time — and was it the fetch, or everything after it?