Zenodo

zenodo.org · Storage · 5 records · JSON

Zenodo anonymous download throughput (the fetch-serving question) Storage★ qualifiesinstitution?card?Dper-object-cap
Zenodo (CERN) Storagecaveatemailno cardDwrite-gated
Zenodo DOI batching (automatic DataCite minting per record) Storagecaveatemailno cardDrequest-rate
Zenodo restricted-access records and secret links (working storage, not only an archive) Storagecaveatemailno cardDper-object-cap
openaire graph Storagefails: quotaemail?card?R

Zenodo anonymous download throughput (the fetch-serving question) Storage

★ qualifiesinstitution?card?Dper-object-cap

zenodo.org/api/records/5656641/files/iPS.zip/content · academic · storage/zenodo-anonymous-download-throughput · JSON · compare

Free tier	n/a — this entry records the measured read path for the 500GB-1TiB/day serving workload unit mixed; metered on unstated
Price	none stated
Per-object cap	not stated
Retention	not stated
Egress	Free and unmetered, and HTTP Range (206) is supported anonymously, which is what makes the parallel read possible: 'accept-ranges: bytes', 'content-range: bytes 0-1023/81165133690'.
Identity	institution (placeholder) inferred from the category 'academic'; the source record states no identity cost, so this is a class assumption, not evidence
Limits	per-ip-shaping 1TiB/day source per-ip-shaping 215 KB/s source request-rate 60 requests per minute source per-object-cap 50 GB per record default; 200 GB absolute ceiling on a single record with the 150 GB allowance pooled in; max 100 files per record (new API: 'a limit of 50GB total in the record (and any given file), and up to 100 files in the record'). source retention-clamped 30-day post-publication deletion window source The throttle is PER CONNECTION, not per IP: 64 simultaneous range requests all returned 206 and aggregate throughput reached my line rate. No aggregate cap observed.
Binding	per-object-cap the per-object cap sets the shard size and therefore the object count; it bounds the total more tightly than any headline quota
Interface	rest, rclone rest
Tooling	zenodo_get (pip) already parallelises; any HTTP client with range support (aria2c -x/-s, rclone non-backend http, curl --parallel) will do.
Composes with	Per-connection shaping ~350-480 KB/s means you need concurrency, not accounts. Measured scaling: 1 conn 0.3 MB/s -> 6 conns 2.33 MB/s -> 16 conns 6.01 MB/s -> 32 conns 11.95 MB/s -> 64 conns 23.07 MB/s. Essentially linear, no knee up to 64. At 23 MB/s that is ~2 TB/day, i.e. the 1 TiB/day serving workload is met with ~2x headroom from one host.
Reliability	Single-stream downloads are painfully slow (~215 KB/s on a 100MB range; the same range took 120s to deliver 45MB). Anything that does not parallelise will appear broken. Reading one file sequentially is a ~50x underuse of the link.
Notes	n/a — this entry records the measured read path for the 500GB-1TiB/day serving workload
Evidence rung	documented The read path and the served byte count were measured against the record's own object. The quota is still a page claim, so the record is documented and carries the probe. Was documented; now documented.
Checked	2026-10-21 (inherited); stale on 2026-11-20
Parsed numbers	`$.limits[0].value` limit:per-ip-shaping 1.0 TiB / day `$.limits[1].value` limit:per-ip-shaping 215.0 KB `$.limits[2].value` limit:request-rate 60.0 requests / minute `$.limits[3].value` limit:per-object-cap 50.0 GB

Evidence (11)

date	source	what it proved
2026-10-22	help.zenodo.org/docs/deposit/manage-quota/	50 GB per record by default, unlimited records, plus a 150 GB pool. Re-read https://help.zenodo.org/docs/deposit/manage-quota/: HTTP 200, 2413 bytes, sha256 c11445727085cd20. Quoted: l: "https://help.zenodo.org/docs/deposit/manage-quota/" fetched_at: "2026-10-22T02:56:33.001Z" --- # Manage storage quota --- Each record comes with a default storage quota of 50GB and you can upload an unlimited number of records under 50GB. For larger files, you also have an additional allowance of up to 150GB that can be distributed across your uploads as needed. You can view detailed information about your quota usage in your
2026-10-22	help.zenodo.org/docs/deposit/manage-quota/	50 GB per record by default, unlimited records, plus a 150 GB pool. Re-read https://help.zenodo.org/docs/deposit/manage-quota/: HTTP 200, 2413 bytes, sha256 c11445727085cd20. Quoted: l: "https://help.zenodo.org/docs/deposit/manage-quota/" fetched_at: "2026-10-22T02:56:33.001Z" --- # Manage storage quota --- Each record comes with a default storage quota of 50GB and you can upload an unlimited number of records under 50GB. For larger files, you also have an additional allowance of up to 150GB that can be distributed across your uploads as needed. You can view detailed information about your quota usage in your
2026-10-21	withheld	probe: control baseline versus same link — speed.cloudflare.com 10MB -> 23.67 MB/s line rate
2026-10-21	withheld	probe: curl -r 0-8388607 zenodo record 5656641 iPS.zip -> 206, 388 KB/s, 8.39 MB, 21.6s (single stream)
2026-10-21	withheld	probe: 32 parallel 2MiB ranges on the same file -> all 206, aggregate 11.95 MB/s, 365 KB/s each
2026-10-21	withheld	probe: 64 parallel 2MiB ranges on the same file -> all 206, aggregate 23.07 MB/s, 352 KB/s each — i.e. full line rate, linear scaling, no per-IP aggregate cap
2026-10-21	probe:https://zenodo.org/api/records/5656641/files/iPS.zip/content	throughput re-probe: parallel ranged GET https://zenodo.org/api/records/5656641/files/iPS.zip/content (7.77 GB file, 15 s each) -> 1 conn 0.48 MB/s, 8 conns 4.93 MB/s, 32 conns 19.68 MB/s, all 206
2026-10-21	zenodo.org/policies	read live 2026-10-21: 'Total files size limit per record is 50GB. Higher quotas can be requested'
2026-10-21	developers.zenodo.org/	read live 2026-10-21: 'a limit of 50GB total in the record (and any given file), and up to 100 files in the record'; rate-limit table 60/min guest, 100/min auth, 30/min search
2026-10-21	withheld	probe: 1/8/32 parallel range GETs -> 0.48 / 4.93 / 19.68 MB/s, all HTTP 206, server: nginx, content-length 7772590480
2026-10-22	probe:https://zenodo.org/api/records/23488904/files/Manual%20T%C3%A9cnico%20Higiene%20Alimentar%20e%20Preven%C3%A7%C3%A3o%20da%20Contamina%C3%A7%C3%A3o%20Cruzada_.pdf/content	ranged GET 2026-10-22: 206 PARTIAL_CONTENT, 1,024 bytes, content-range bytes 0-1023/2556616, accept-ranges: bytes, server nginx; anonymous, no key

More fields (9)

{
 "verified_in_pass": [
  {
   "url": "https://help.zenodo.org/docs/deposit/manage-quota/",
   "date": "2026-10-22",
   "via": "read-broker",
   "http_status": 200,
   "bytes": 2413,
   "sha256": "c11445727085cd202d2e0dbbb89721aec071253db935a3816fc347ef0228c92e",
   "pattern_found": true,
   "what_changed": "no change: the page still states the claim",
   "capture": "captures\\zenodo-cern-help-zenodo-org-docs-deposit-manage-quota-.txt"
  }
 ],
 "verify_file": "verify/zenodo.json",
 "verify_quota": "50 GB per record by default, unlimited records, plus a 150 GB per-account allowance that can be pooled onto a single record (=> 200 GB max for one record). Verbatim: 'Each record comes with a default storage quota of 50GB and you can upload an unlimited number of records under 50GB. For larger files, you also have an additional allowance of up to 150GB that can be distributed across your uploads as needed.' Policy page: 'Total files size limit per record is 50GB. Higher quotas can be requested and granted on a case-by-case basis.'",
 "verify_per_unit_cap": "50 GB per record default; 200 GB absolute ceiling on a single record with the 150 GB allowance pooled in; max 100 files per record (new API: 'a limit of 50GB total in the record (and any given file), and up to 100 files in the record').",
 "verify_probe": "parallel ranged GET https://zenodo.org/api/records/5656641/files/iPS.zip/content (7.77 GB file, 15 s each) -> 1 conn 0.48 MB/s, 8 conns 4.93 MB/s, 32 conns 19.68 MB/s, all 206",
 "verify_notes": "All quota numbers confirmed unchanged. The dossier's throughput claim is directionally right and I reproduced it independently today: the throttle is PER CONNECTION, not per IP or per account. 1 conn 0.48 MB/s -> 8 conns 4.93 MB/s (10.3x for 8x) -> 32 conns 19.68 MB/s (4.0x for 4x, perfectly linear). 19.68 MB/s = ~1.70 TB/day, so one host meets the 1 TiB/day serving workload with ~1.7x headroom. Correction to the dossier's scaling table: my 32-conn number is 19.7 MB/s where the dossier recorded 11.95 MB/s — today's link is faster, the shape (linear, no knee) is identical. The 416s I saw were self-inflicted (my 32nd offset ran past the 7.77 GB EOF), not throttling. Also confirmed the new-API file cap the dossier did not state: 100 files per record, which matters for sharding — 50 GB must be split into no more than 100 files, i.e. >=500 MB per file.",
 "verify_verdict": "qualifies-with-caveat",
 "verify_confidence": "high",
 "changed_since_dossier": false
}

Unknown or withheld values (11)

$.evidence[2].url private-url
$.evidence[3].url private-url
$.evidence[4].url private-url
$.evidence[5].url private-url
$.evidence[9].url private-url
$.free_tier.notes process
$.identity_cost.kind identity-defaulted
$.per_object_cap.notes not-extracted
$.per_object_cap.stated not-extracted
$.retention.notes not-extracted
$.retention.stated not-extracted

Zenodo (CERN) Storage

caveatemailno cardDwrite-gated

zenodo.org/ · academic data repository · storage/zenodo · JSON · compare

Free tier	50 GB per record with no cap on the number of records, in a shared 150 GB per-account pool that CERN states may change unit GB; metered on stored-bytes; CERN funds the service, so the quota is a policy that can move; it is not a purchased allowance with a contract behind it.
Price	none stated
Per-object cap	50 GB per record (50000000000 bytes)
Retention	permanent by policy; a DOI is minted per record and the record is citable forever
Egress	free, no metered allowance; per-connection throttled rather than byte-capped
Identity	email An email address and a password. No institution, no affiliation check, no card. ORCID and GitHub logins are offered and neither is required.
Limits	per-object-cap 50 GB per record, and 150 GB total per account source write-gated a DOI is minted on publish and the record is then immutable except for metadata; files may only be added in a 30-day window source Two constraints bind and they bind in different places: the cap sets the record size, and the write gate means the corpus cannot be edited after publication. A second record is the alternative route and it costs a second DOI.
Binding	write-gated The cap is generous for a user's shard sizes; the gate is what decides the workflow, because a mistake after publication cannot be corrected in place, only superseded by a new version.
Interface	rest, s3-compatible REST deposit API with a token, plus an S3-compatible endpoint for large files. Not a WebDAV or rclone-native backend. endpoint: https://zenodo.org/api
Tooling	requests or curl against the deposit API; the S3 endpoint needs a generated key pair
Composes with	The useful chain is write-once archive plus a parallel ranged reader: Zenodo holds the durable copy and a Worker or a ranged client serves it, because a single stream is slow but many streams are not.
Reliability	CERN-operated and long-lived; the failure mode is policy change rather than downtime. Records are immutable after publication, so a quota reduction would affect new deposits and not existing ones. The binding limit on reading is the per-connection throttle, which parallel ranged GETs defeat; see zenodo-anonymous-download-throughput.
Notes	Split across three sub-finding records that each answer one question: anonymous download throughput, DOI batching, and restricted-access records as working storage. This record is the provider itself, so that a document citing Zenodo has one canonical target.
Evidence rung	documented The quota and the write gate are read from CERN's own help pages on 2026-10-21; the throughput is measured separately in zenodo-anonymous-download-throughput.
Checked	2026-10-21 (live); stale on 2026-11-20
Parsed numbers	`$.limits[0].value` limit:per-object-cap 50.0 GB

Evidence (3)

date	source	what it proved
2026-10-21	help.zenodo.org/docs/deposit/manage-files/	50 GB per record and a 150 GB per-account pool, stated as a shared allowance rather than a per-record guarantee
2026-10-21	help.zenodo.org/docs/deposit/publish/	publication mints a DOI and files become immutable, with a 30-day window for additions
2026-10-21	about.zenodo.org/policies/	the retention policy: records are retained permanently and citable by DOI

Unknown or withheld values (1)

$.notes partly-held

Zenodo DOI batching (automatic DataCite minting per record) Storage

caveatemailno cardDrequest-rate

developers.zenodo.org/ · academic repository, identifier behaviour · storage/zenodo-doi-batching-automatic-datacite-minting · JSON · compare

Free tier	One DOI per record, automatically, free, and unlimited records. DOI count is therefore not a constraint on sharding: a 410-record archive is also 410 citable handles at no extra cost unit objects; metered on object-count; This record exists because the corpus treated the DOI as a property of Zenodo rather than as a mechanism that decides how far the archive can be sharded
Price	none stated
Per-object cap	One DOI per record, and the deposition response carries a reserved DOI already set through prereserve_doi, so a batch job gets a citable handle without a separate call
Retention	DOIs are permanent and cannot be reused or reassigned. Deleting a record within 30 days revokes the DOI, after which it tombstones. A record cannot be un-published to reclaim the identifier
Egress	Not applicable to the identifier itself. Retrieval of the deposited bytes is free and unmetered, and the read path is measured in the sibling record
Identity	email an email address, GitHub or ORCID account. No institution is needed to mint a DOI, which is the unusual part
Limits	request-rate 100 requests per minute authenticated, 30 per minute on the search API, which sets the batch size per hour rather than any record count cap source retention-clamped a DOI is revoked if the record is deleted inside the 30-day window, and tombstones after that source Content outside the repository's scope is removed and its DOI revoked, which is the only stated ground for losing an identifier after the 30-day window
Binding	request-rate Nothing limits the number of DOIs. What limits a batch job is the authenticated request rate, so the practical ceiling is records per hour and not records per account
Interface	rest POST /api/deposit/depositions returns a record with a reserved DOI already set, so one call per record yields one identifier
Tooling	any HTTP client. zenodo_get and zenodo-cli both wrap the same API for the read side; there is no rclone backend
Composes with	Because every record gets a DOI for free, a 410-record archive is also 410 citable handles with zero extra work. This is the mechanism that makes the unlimited-records story practical rather than merely permitted: there is no per-DOI cost and no approval step, so the archive can be sharded to the record boundary and every shard stays citable
Reliability	Batch-creating hundreds of records is API-rate-bound only and not quota-bound, so the operational risk is a batch that half-completes and leaves Pending files rather than one that hits a ceiling
Notes	A sub-finding of Zenodo, written as its own record because the DOI mechanism is what makes the record-per-50-GB sharding practical and the corpus did not state it anywhere. this is that record. The quota, the API and the 30-day window belong to the parent finding and are not restated as new facts here
Evidence rung	documented What would raise it is a probe that creates a deposition anonymously or with a token and reads the reserved DOI back
Checked	2026-10-21 (live); stale on 2026-11-20
Parsed numbers	`$.limits[0].value` limit:request-rate 100.0 requests / minute

Evidence (3)

date	source	what it proved
2026-10-21	developers.zenodo.org/	the quickstart creates a deposition, receives a 'doi' and 'prereserve_doi' in the response, uploads through a bucket URL, then POSTs to /publish, and notes the newer file API has 'a limit of 50GB total in the record (and any given file), and up to 100 files in the record'
2026-10-21	about.zenodo.org/policies/	'Content not considered to fall under the scope of the repository will be removed and associated DOIs issued by Zenodo revoked', and on withdrawal that the DOI and the URL of the original object are retained
2026-10-21	help.zenodo.org/docs/deposit/manage-records/	deletion is owner-initiated within 30 days after publication; outside that window only justified cases are considered

More fields (7)

{
 "parent_finding": "Zenodo's public deposit path at 50 GB per record times unlimited records",
 "sibling_record": "dossier/storage/zenodo-anonymous-download-throughput.json covers the measured read path",
 "sub_finding": true,
 "what_the_parent_record_owns": "the deposit API, the quota arithmetic, the 30-day window and the visibility model",
 "what_this_record_owns": "that a DOI is minted per record at no cost, which is what allows the archive to be sharded to the record boundary without losing citability",
 "doi_per_record": true,
 "record_count_for_20_tib": 410
}

Zenodo restricted-access records and secret links (working storage, not only an archive) Storage

caveatemailno cardDper-object-cap

help.zenodo.org/docs/share/link-sharing/ · academic repository, restricted visibility · storage/zenodo-restricted-access-records-and-secret-links · JSON · compare

Free tier	The same 50 GB per record and 150 GB per-account pool as the public path. Restricting the files neither reduces nor refunds the quota, so the capacity is identical unit GB; metered on stored-bytes; This record exists because the corpus held Zenodo's public deposit path and not its restricted one. They are the same quota with a different visibility flag, and the difference decides whether Zenodo can be a working set or only an archive
Price	none stated
Per-object cap	50 GB per record on the default quota, with the 150 GB account pool distributable across records, and a hard 100 files per record (50000000000 bytes)
Retention	A record cannot be deleted after 30 days. Restricted records carry the same rule, so a restricted record is as permanent as a public one and its quota is consumed monotonically
Egress	Free. A secret link grants 'Can view' on restricted or embargoed files of all current and future versions of that record, with optional expiry
Identity	email an email address, GitHub or ORCID account.
Limits	per-object-cap 50 GB per record on the default quota, 100 files per record source retention-clamped a record cannot be deleted after 30 days, restricted or not source request-rate 100 requests per minute authenticated; 30 per minute on the search API source Metadata is always public even when the files are restricted, so titles, descriptions and the minted DOI leak. That is a property of the visibility model and not a defect in this record
Binding	per-object-cap The quota and the visibility are independent, so restricting a record buys privacy and no capacity. What binds is the 50 GB per-record ceiling, which sets the record count at about 410 for the 20 TiB archive whether the records are public or restricted
Interface	rest the same deposition API; visibility is a field on the draft, set to restricted with an embargo date or a share link, and share links are managed from the record's Links tab
Tooling	any HTTP client for the deposition and file APIs, working in the same way as the public path. There is no rclone backend, so uploads are plain HTTP PUT against a bucket URL
Composes with	This is what turns Zenodo from a cold archive into something usable as a hot working set: the client can keep data off the public index while still holding 50 GB times N, and still read it programmatically with a token or a shared link. It composes with the 32-connection parallel read measured on the public path, because the throttle is per connection and not per visibility
Reliability	Answers the working-storage question: workable for private data, but every record still carries permanently public metadata and a DOI, so it is a leaky private tier and not a private bucket. An interrupted upload leaves a Pending file that must be removed by hand
Notes	A sub-finding of Zenodo, written as its own record because the corpus carried the public deposit path and not the restricted one, and the difference is the whole working-storage question. this is that record. It does not duplicate the main provider: the quota, the API and the lifecycle are the parent record's, and this one adds only the visibility field and what it costs
Evidence rung	documented What would raise it is a probe of a restricted record read through a secret link
Checked	2026-10-21 (live); stale on 2026-11-20
Parsed numbers	`$.limits[0].value` limit:per-object-cap 50.0 GB `$.limits[2].value` limit:request-rate 100.0 requests / minute

Evidence (4)

date	source	what it proved
2026-10-21	help.zenodo.org/docs/share/link-sharing/	'Link sharing enables you to create a secret link which provides access to your record. The link can also have an expiry date.' and 'Can view: Grants access to view restricted/embargoed files of all current and future versions'
2026-10-21	help.zenodo.org/docs/about/whats-changed/	'the access right field has now been changed into a visibility field with two options (metadata is always public)'
2026-10-21	help.zenodo.org/docs/deposit/manage-quota/	each record comes with a default quota of 50 GB and an additional 150 GB allowance distributable across uploads, with no account-level total documented
2026-10-21	help.zenodo.org/docs/deposit/manage-records/	records can be deleted by their owner within 30 days after publication, and outside that window only in justified cases

More fields (5)

{
 "parent_finding": null,
 "sibling_record": "dossier/storage/zenodo-anonymous-download-throughput.json covers the measured read path",
 "sub_finding": true,
 "what_the_parent_record_owns": "the deposit API, the quota arithmetic, the 30-day window and the DOI behaviour",
 "what_this_record_owns": "the visibility field, secret links, and the leak of metadata under a restricted record"
}

Unknown or withheld values (1)

$.extras.parent_finding withheld

openaire graph Storage

fails: quotaemail?card?R

zenodo.org/communities/openaire-research-graph/about · rejected-provider · storage/openaire-graph · JSON · compare

Free tier	Not a repository — its dumps are published onto Zenodo (community 'openaire-research-graph'), i.e. it consumes the same 50 GB/record budget everyone else does. 10.8 GB per part. unit none; metered on none
Price	none stated
Per-object cap	not recorded
Retention	not recorded
Egress	not recorded
Identity	email (placeholder) not published
Binding	none no constraint of a named kind was recorded; the verdict rests on the quota sentence rather than on a named limit
Interface	unknown
Tooling	not recorded
Composes with	not recorded
Reliability	Not a repository — its dumps are published onto Zenodo (community 'openaire-research-graph'), i.e. it consumes the same 50 GB/record budget everyone else does. 10.8 GB per part.
Notes	Not a repository — its dumps are published onto Zenodo (community 'openaire-research-graph'), i.e. it consumes the same 50 GB/record budget everyone else does. 10.8 GB per part.
Evidence rung	reported
Checked	2026-10-21 (inherited); stale on 2026-11-04

Evidence (2)

date	source	what it proved
2026-10-21	zenodo.org/communities/openaire-research-graph/about	Not a repository — its dumps are published onto Zenodo (community 'openaire-research-graph'), i.e. it consumes the same 50 GB/record budget everyone else does. 10.8 GB per part.
2026-10-21	zenodo.org/records/17725827	cited as the basis of the rejection: Not a repository — its dumps are published onto Zenodo (community 'openaire-research-graph'), i.e. it consumes the same 50 GB/record budget everyone else does. 10.8 GB per part.

More fields (1)

{
 "dead_end": {
  "failure_class": "quota",
  "why": "Not a repository — its dumps are published *onto* Zenodo (community 'openaire-research-graph'), i.e. it consumes the same 50 GB/record budget everyone else does. 10.8 GB per part.",
  "retry_when": null,
  "first_recorded": "2026-10-21"
 }
}

Unknown or withheld values (15)

$.chaining not-recorded
$.confidence_note withheld
$.egress.terms not-recorded
$.extras.dead_end.retry_when process
$.free_tier.notes process
$.identity_cost.detail defaulted
$.identity_cost.kind identity-defaulted
$.interface interface-unknown
$.interface_detail withheld
$.limits_note process
$.per_object_cap.notes not-recorded
$.per_object_cap.stated not-recorded
$.retention.notes process
$.retention.stated not-recorded
$.tooling not-recorded