Systems Software Data: Package Registries, Vulnerability Records and Fleet Telemetry · Head-to-head
crates.io - Rust Package Registry API vs deps.dev - Open Source Insights API
Which systems software data: package registries, vulnerability records and fleet telemetry data fits your job: crates.io - Rust Package Registry API, or deps.dev - Open Source Insights API. API, files, or your warehouse. Daily, weekly, or hourly.
crates.io - Rust Package Registry API
deps.dev - Open Source Insights API
Where the fields line up
No shared field names. These two answer different questions.
| Field | crates.io - Rust Package Registry API | deps.dev - Open Source Insights API |
|---|---|---|
Crate identifier and maintainer-written description | documented | not in this set |
All-time download count and trailing roughly 90-day download count | documented | not in this set |
Highest version, highest stable version and newest version markers | documented | not in this set |
Created and updated lifecycle timestamps | documented | not in this set |
Declared source repository URL | documented | not in this set |
Registry-wide counters: registered crates and all-time downloads | documented | not in this set |
Aggregate keyword and category counts | documented | not in this set |
packageKey.system | not in this set | Package ecosystem identifier: GO, RUBYGEMS, NPM, CARGO, MAVEN, PYPI or NUGET. The first half of every join key in the corpus. |
packageKey.name | not in this set | Package name within its ecosystem, exactly as the registry spells it. |
versionKey.version | not in this set | Version string as published to the registry; the third leg of the natural key. |
publishedAt | not in this set | Publication timestamp of the package version. The field that turns repeated deliveries into release-velocity timelines. |
isDefault | not in this set | Whether this version is the registry's default or latest release. |
What each contains
Pick by fit, not by loyalty.
| crates.io - Rust Package Registry API | deps.dev - Open Source Insights API | |
|---|---|---|
| Primary identifier | `id` - the crate name (`serde`) | `packageKey.system` + `packageKey.name` - ecosystem enum plus name (`CARGO`, `serde`) |
| Version identifier | `max_version`, `max_stable_version`, `newest_version` - three pointers, no version list | `versionKey.version` per entry in a full versions array (serde: 300+ entries) |
| Publication timestamp | `created_at` per crate (first publish, 2014-12-05 for serde) and `updated_at` for last metadata change | `publishedAt` per version (2026-07-18T23:05:13Z for serde 1.0.229) |
| Demand measure | `downloads` all-time (1,293,940,052 for serde) plus `recent_downloads` over a rolling ~90-day window | None carried - attention arrives instead as project `starsCount` (10,779) |
| Security signals | None native - no advisory columns in the documented dictionary | `advisoryKeys` - OSV/GHSA identifiers attached per version (`GHSA-29mw-wpgm-hmr9`) |
| Dependency structure | Registry-wide coverage of dependencies as a concept, but the documented crate record exposes no edge list | `nodes.relation` (SELF/DIRECT/INDIRECT) joined by `edges.requirement` strings (`^1.0`) - the resolved transitive graph |
| Health and quality | `updated_at` recency proxies maintenance; nothing scored | OpenSSF Scorecard aggregate plus per-check results, `openIssuesCount`, forks, OSS-Fuzz status |
| Lifecycle state | Implied only - gaps between `newest_version` and `max_stable_version` hint at yanked or prerelease activity | `isDeprecated` plus `deprecatedReason` per version, `isDefault` marking the current release |
| Rollups and classification | Summary counters (`num_crates` 320,253, `num_downloads` 408 billion) plus keyword and category tallies (14,989 CLI, 9,927 cryptography) | None carried - queries address one package, version, project or advisory at a time |
Where they're equivalent
More than their opposite temperaments suggest.
- Both are first-party platform records - one built by the Rust registry operators, one by Google's Open Source Insights team, so provenance is authoritative on each side.
- Both cover the same Cargo universe: every CARGO package in deps.dev originates as a crates.io publication, so package-level recall matches on the Rust side.
- Both key on name-plus-version and stamp every version with a publication timestamp; serde 1.0.229 reads identically timed on either side (2026-07-18T23:05:13Z).
- Both resolve to the same source repositories, exposing the GitHub project behind the package name.
- Both refresh daily and carry fully verified field dictionaries - definitions checked, not inferred, a standard met by roughly 86 percent of the catalog.
- Both score 10 out of 10, tied at the top of the rubric and of this slice's 17 records.
Fair questions
Do the two field dictionaries overlap?
At the spine only. Both key records on a package name inside an ecosystem, both carry version identifiers and publication timestamps, and both point at the same upstream repositories. Zero column names collide.
Does deps.dev cover anything besides Rust?
Six more ecosystems: npm, PyPI, Go, Maven, NuGet and RubyGems alongside Cargo - one dictionary across all seven. crates.io is deliberately single-ecosystem and correspondingly deeper on Rust demand: keyword and category rollups, registry-wide summary counters and a decade-long publication history.
How do the two records join?
Cleanly, because deps.dev echoes the registry's own strings: crates.io `id` plus `max_version` maps to deps.dev `packageKey.name` plus `versionKey.version` (`serde`, `1.0.229` on both sides).
Can Datadory deliver both datasets together?
Yes - sample both, pick by fit, or take both in one feed. Each arrives normalized to its documented field dictionary with sample rows attached for validation, merged on a resolved crate-plus-version key if you want them together, delivered daily, weekly, or hourly - your call - next to the rest of the systems software catalog.