Internet Services & Infrastructure Data: Routing Registries, BGP Archives and Domain Intelligence · Head-to-head
RIPE Database (WHOIS & Routing Registry) vs RIPEstat Data API
Which internet services & infrastructure data: routing registries, bgp archives and domain intelligence data fits your job: RIPE Database, or RIPEstat Data API. API, files, or your warehouse. Daily, weekly, or hourly.
RIPE Database (WHOIS & Routing Registry)
RIPEstat Data API
Coverage, side by side
| RIPE Database | RIPEstat Data API | |
|---|---|---|
| Geographic | Europe, the Middle East and parts of Central Asia; 75 member countries | Global, with views across all five Regional Internet Registries |
| Temporal | Created stamps to the early 1990s; per-object created and last-modified throughout | Point-in-time replies stamped with query_time; routing-history and historical-whois reach back years |
What each contains
They tie on 2 attributes. Pick by fit, not by loyalty.
| RIPE Database | RIPEstat Data API | |
|---|---|---|
| Publisher | RIPE NCC | RIPE NCC |
| Role in the registry stack | Authoritative registration ledger for its service region | Aggregation layer drawing on more than 35 underlying datasets |
| Subject lens | Who holds which IPv4/IPv6 ranges and ASNs, the contacts behind them, declared routing policy, reverse-DNS delegations | Per-network answers: routing history, announced prefixes, geolocation, WHOIS, reverse DNS, RPKI |
| Field dictionary | 22 documented fields, verified during research | 13 documented envelope fields, verified during research |
| Geographic coverage | Europe, the Middle East and parts of Central Asia; 75 member countries | Global, with views across all five Regional Internet Registries |
| Temporal coverage | Created stamps to the early 1990s; per-object created and last-modified throughout | Point-in-time replies stamped with query_time; routing-history and historical-whois reach back years |
| Detail level | Whole RPSL objects across roughly 21 object classes | Per-resource answers across 60-plus named lookups |
| Observation signal | None - policy is declared, not observed | Announcement state, ASN neighbourhoods and routing history as recorded |
| Best for | Holder forensics, contact routing and citation-grade governance work | Feature enrichment, monitoring and any question starting 'what is known about this network' |
What each does better
RIPE Database
Whole-object depth, proven with a row. One live record reads: inetnum 193.0.0.0 - 193.0.7.255, netname RIPE-NCC, country NL, status ASSIGNED PA, org ORG-RIEN1-RIPE, created 2003-03-17T12:15:57Z, last-modified 2026-03-19T09:08:35Z. Every object arrives that fully specified - see whois records for why registration completeness matters downstream.
Contacts as first-class fields. admin-c, tech-c and abuse-c nic-handles plus person / nic-hdl objects turn an address block into accountable people and roles, with mnt-by naming the maintainers authorised to change the record. RIPEstat offers only a purpose-built abuse-contact lookup in exchange.
Declared policy, not inferred policy. import / mp-import and export / mp-export carry the routing policy a network publishes for itself, alongside route, route6 and origin objects tying prefixes to originating ASNs. This is intent on the record - see autonomous system numbers - and no observation layer can synthesize it after the fact.
Deep time. created stamps reach back to the early 1990s and every object carries created plus last-modified, which is why journalists, academics and students score this record at the maximum persona relevance of 3 for citation-grade governance work.
RIPEstat Data API
Breadth first: 60-plus named lookups aggregating more than 35 underlying datasets, spanning routing history, announced prefixes, ASN neighbours, geolocation, WHOIS including historical WHOIS, allocation and transfer history, reverse DNS, DNS blocklists, RPKI validation, abuse-contact finding and country resource lists. Geolocation, RPKI and reverse DNS have no counterpart anywhere in the database's dictionary.
Observation, proven with a row. Ask about 193.0.6.0/24 and the reply resolves it to 193.0.0.0/21, announced true, originating from AS3333 under the holder name RIPE-NCC-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC), sitting in block 193.0.0.0/8 RIPE NCC (Status: ALLOCATED), stamped query_time 2026-08-21T08:00:00. A ris-peers lookup on AS3333 returns route-server peers such as rrc00 carrying 109,482 IPv4 prefixes - see border gateway protocol.
Global by construction. Any routed network worldwide answers, with views across all five Regional Internet Registries, where the database stops at its own 75-member-country region.
One consistent envelope. Every reply reports status, schema version, cached state and query_time, and per-call metadata documents methodology and availability windows - the same contract whether the question is routing, geography or registration.
Where they're equivalent
More than the field counts suggest. Both dictionaries were verified during research, both records score 9/10, and both speak the registry's own language: because RIPEstat re-serves registry records among its sources, a holder name or allocation status read on one side lines up with the same value on the other, which makes joining the pair unusually painless. Both organise everything around internet number resources - addresses, prefixes, ASNs - rather than hostnames or domains; the domain spine of this slice belongs to other records entirely. Neither grades the truth of what it reports: Datadory's rubric weighs documentation, reliability and freshness, not accuracy guarantees, so a routing dispute still needs a second witness. And neither hands over a ready-made longitudinal series - trend work means repeated sampling on the database side and window-by-window questions on the RIPEstat side.
The verdict
Verdict: sample both, pick by fit - they are two halves of one registry, not competitors.
Take RIPE Database (WHOIS & Routing Registry) if your question names a holder. Who runs this range, whom do I contact, what do they declare they announce, when did this allocation appear and change - anything answered by reading the ledger. Accept its frame: one region, and policy as written.
Accept its frame: a thirteen-field envelope and depth that varies by lookup.
Sample both, pick by fit. See RIPE Database · See RIPEstat Data API
Or take both in one feed
Yes - they complete each other, and the workflow is short. Start in the ledger: the database establishes who holds a resource, with contacts and declared policy attached. Then observe: RIPEstat reports whether that resource announces, from where, and how that has changed.
Alignment is friendlier than most merges because the resource identifiers coincide: the inetnum value 193.0.0.0 - 193.0.7.255 read as a registry object reappears verbatim as the first record of RIPEstat's whois answer for 193.0.6.0/24. Two things need handling. Declared export policy and observed announcements disagree sometimes - and the disagreement is usually the finding, not the defect. And units differ, so RPSL text needs typing into the envelope's structured columns. We handle both upstream, delivered daily, weekly, or hourly - your call. Or take both in one feed.
API, files, or your warehouse. Daily, weekly, or hourly.
Fair questions
Do the two datasets cover the same ground?
One strip of it. RIPEstat re-serves registry records through whois and historical-whois lookups, and its prefix-overview returns the same range, holder and block status you would read in the database itself. Everything else splits: declared policy versus observed announcements, a 75-country region versus global coverage, whole RPSL objects versus per-resource answers.
Which dataset documents more fields per record?
The RIPE Database, by nine: 22 documented fields against RIPEstat's 13. The gap is nearly all registration substance - org and sponsoring-org references, admin-c, tech-c and abuse-c handles, mnt-by maintainers, status enums and the import/export policy expressions. RIPEstat's thirteen mostly describe the reply envelope - status, schema version, cache flag, query_time - plus the payload.
Which dataset should sales and growth teams sample first?
The RIPE Database, which carries the maximum persona relevance of 3 for that team: organisation references and abuse-c contacts turn address blocks into accountable companies and contacts across 75 member countries. RIPEstat earns its place afterwards, when a prospect's network needs a geolocation, routing or RPKI cross-check before outreach.
Can Datadory deliver both datasets together?
Yes - separately or merged onto one IP, prefix or ASN list, delivered daily, weekly, or hourly, your call. Each arrives normalized to its documented dictionary (22 fields on the database side, 13 on the RIPEstat side) with sample rows for inspection before anything ships. Alignment runs on the resource identifiers themselves, which match on both sides.