Harvard Dataverse: 302,000 datasets, no account needed,...

Most academic data lives in one of two bad places. It is either an attachment on a paper behind a paywall, or a link in a footnote that stopped resolving in 2019.

Harvard Dataverse is the third option, and it is quietly enormous. When I measured it on 9 August 2026 its search index returned 302,139 datasets and 5,436,791 files, and it had served 161,092,378 file downloads since it opened. About 116,000 of those datasets are Harvard's own deposits and the rest is metadata it harvests from other repositories, a distinction that turns out to matter. You do not need an account to read any of it. You do not need a Harvard affiliation to put your own work in it.

I spent a day working against it properly, and there are a few things about it that the front page does not tell you.

What it actually is

There are three separate things all called some version of "Dataverse," and mixing them up will waste an afternoon.

Dataverse the software is an open source Java application for hosting research data, developed at Harvard's Institute for Quantitative Social Science. The project's own description calls it "an open source web application to share, preserve, cite, explore, and analyze research data." It is Apache 2.0 licensed and anyone can run it.

A Dataverse repository is one running installation of that software. There are 150 of them worldwide across 44 countries according to the registry that feeds the project's own installation map, with the heaviest concentrations in the United States (21), Germany (15), Brazil (14) and Poland (14).

Harvard Dataverse is the flagship installation, at dataverse.harvard.edu, run by Harvard. Its API reports version 6.10.1, one release behind the current 6.11 line. That is the one this post is about.

Inside a repository, the nesting goes: collections contain datasets, datasets contain files. Confusingly, a collection is also called a dataverse. Harvard Dataverse currently holds 9,332 of them.

The design idea behind all of this is stated bluntly on the project's about page, and it is worth quoting because it explains everything else:

Before the Dataverse Project, researchers were forced to choose between receiving credit for their data, by controlling distribution themselves but without long term preservation guarantees, or having long term preservation guarantees, by sending it to a professional archive but without receiving much credit.

Every design decision downstream of that, the per-dataset DOI, the formal citation string, the version numbers, the download counters, exists to make depositing data feel like publishing rather than like filing.

Who runs it and who pays

Harvard Dataverse is not one team. Three Harvard units split it: IQSS leads the software and, through the Open Data Assistance Program, provides user support; Harvard Library Technology Services handles hosting and backups; and Harvard University Information Technology provides infrastructure.

Gary King is listed as Founder and Principal Investigator, and he is also the Director of IQSS. The lineage goes back further than most people assume. The project's history page traces it to the Virtual Data Center project, which ran from 1997 to 2006 as a collaboration between the Harvard-MIT Data Center, now part of IQSS, and the Harvard University Library, with precursors dating to 1987. The canonical citation is King's 2007 paper, "An Introduction to the Dataverse Network as an Infrastructure for Data Sharing," in Sociological Methods & Research.

On money, the about page says it plainly: "Funded by Harvard with additional support from the Alfred P. Sloan Foundation, National Science Foundation, National Institutes of Health, Helmsley Charitable Trust, IQSS's Henry A. Murray Research Archive, and many others."

No dollar amounts are published anywhere I could find, and no grant numbers. That is a real gap if you are trying to assess how durable this is. What you get instead is an institution making a preservation commitment in writing, which I will come back to.

What it costs

This is the part where the answer is more interesting than "it's free."

Reading is free and anonymous. I downloaded a file from a published dataset with no account, no key, and no headers beyond a normal browser identifier. Search is free. Metadata is free. There is no tier, no seat, no quota on reading.

Depositing is free too, up to a ceiling that is stated in exactly one place. From the researchers page:

All researchers from any discipline, both inside and out of the Harvard University community, can deposit files of up to 2.5GB, and store up to 1TB of data on the Harvard Dataverse Repository.

So: 2.5 GB per file, 1 TB total, open to anybody on earth. Free curation and data management support covers collections up to 1.0 TB for non-Harvard depositors and 2.5 TB for Harvard affiliates.

Above that you are into Large Data Services, which are fee-based and which publish an actual price list. The current version is dated 23 March 2026, and the storage rates are:

Service	Access	Storage cost
Large Data Basic Service: NESE Tape	Globus	$11 / TB / year
Large Data Basic Service: Globus NESE Disk	Globus	$22 / TB / year
Large Data On-Demand Service: S3 NESE Disk	S3/HTTP	$22 / TB / year
Large Data Cold Storage: NESE Tape	Globus	$11 / TB / year
Large Data On-Demand Service: AWS S3	S3/HTTP	$276 / TB / year

On top of raw storage there is an overhead fee of 20 percent for Harvard affiliates and 30 percent for everyone else. Uploads are free on every tier. Downloads are free on every tier except AWS S3, which adds $90 per TB of egress. The same document puts Wasabi at $84 per TB per year as a comparison point.

Consultations are free for two hours if you are at Harvard and one hour if you are not. Beyond that it is $200 per hour for Harvard and $300 per hour for everyone else. Letters of support are free either way.

The tape tiers come with real constraints that are easy to miss. NESE Tape has a minimum file size of 100 MB, which means a dataset of ten thousand small CSVs is the wrong shape for it. The Globus tiers cap out at 100 files per dataset as a hard limit, with 50 as the recommended target. And Globus transfers have to be started in the Dataverse web interface, because there is no scriptable path for them.

That last one matters if you were planning to automate anything. The regular API is fully scriptable. The large-data tape path is not.

The API, which is the actual reason to care

Everything below runs with no account and no key. I ran all of it.

Start with search. One caveat before you try this from a web page: the guides say the Search API allows cross-origin requests, and demo.dataverse.org does send Access-Control-Allow-Origin: *, but Harvard's own installation sends no CORS headers at all, so a browser fetch() from another origin fails outright. From the command line it is fine:

curl "https://dataverse.harvard.edu/api/search?q=*&type=dataset&per_page=1"

That returned total_count: 302139 for me. Swap type=file and you get 5,436,791. Swap type=dataverse and you get 9,332.

Now pull a real dataset by its DOI. This one is the COVID-19 daily case file with US basemaps, deposited by the Spatial Data Lab:

curl "https://dataverse.harvard.edu/api/datasets/:persistentId/?persistentId=doi:10.7910/DVN/HIDLTK"

The response tells you the license is CC0 1.0, that the dataset has 12 files, and that the current version is 67.1. That is not a typo. Sixty-seven major versions, each one a citable snapshot, each one still retrievable. If you have ever tried to reproduce an analysis and discovered the data moved under you, you understand why that number is the single best argument for this whole system.

Then take a file id out of that response and just fetch it:

curl -L "https://dataverse.harvard.edu/api/access/datafile/3758782" -o index.txt

That is the whole workflow. Search, resolve, download. Three commands, no credentials.

Two more endpoints are worth knowing. Usage stats per dataset are public:

curl "https://dataverse.harvard.edu/api/datasets/3679837/makeDataCount/viewsTotal"
curl "https://dataverse.harvard.edu/api/datasets/3679837/makeDataCount/downloadsTotal"

For that COVID dataset I got 28,688 views and 12,299 downloads. Those are Make Data Count figures, a standardised counting scheme, not a raw hit counter. Being able to see how much a dataset is actually used, before you build on it, is a genuinely useful filter.

And metadata exports come in a pile of standard formats:

curl "https://dataverse.harvard.edu/api/info/exportFormats"

DataCite, Dublin Core, OpenAIRE, OAI_ORE and more. If you are feeding a catalogue or a discovery layer, you do not have to parse the native JSON.

Client libraries exist for Python, R, JavaScript, Java, C/C++, Go, Julia, Ruby and Rust. The guides label the C/C++, Java, JavaScript, Julia and R ones official; the rest, including Python's widely used pyDataverse, are community projects, and there is no official PHP library at all. The R client is the dataverse package on CRAN. There is also DVUploader, a standalone Java command-line uploader for bulk deposits. Write operations need a token; reads do not.

The counting trap

Here is the one that cost me time, and it will cost you time too.

Ask the Search API how many datasets exist and you get 302,139. Ask the Metrics API the same question and you get 115,999.

curl "https://dataverse.harvard.edu/api/info/metrics/datasets"

Both numbers are correct. They are counting different things, and the Search API will tell you the split if you ask it for facets:

curl "https://dataverse.harvard.edu/api/search?q=*&type=dataset&per_page=1&show_facets=true"

The metadataSource facet comes back as Harvested 186,202, Harvard Dataverse 115,937. Harvard harvests metadata from other repositories as well as holding its own deposits. The metrics count covers only locally deposited, currently released datasets. Search covers everything the index knows about. Roughly 186,000 records are other people's data that Harvard is helping you find but is not storing.

The same split shows up in the file counts: 3,406,695 from metrics, 5,436,791 from search.

If you are going to quote a number about Harvard Dataverse in anything, decide first which question you are answering. "How much data does Harvard hold" and "how much data can I find through Harvard" have different answers, and they differ by a factor of about two and a half.

A related gotcha: several documented metrics endpoints never finish on this installation. filedownloads, uniquedownloads, files/byType and downloads/monthly all hang for about a minute and then return an HTML gateway-timeout page. A client with a short timeout sees an empty body; a client that parses blindly gets HTML where it expected JSON. Neither one is zero. Do not write a parser that treats it as one.

What is actually in there

The same facet trick answers the more interesting question, which is what kind of repository this really is.

By subject: Social Sciences 49,262 datasets, Arts and Humanities 32,377, Medicine, Health and Life Sciences 12,712, Earth and Environmental Sciences 6,549, Law 6,078. Despite the general-purpose branding, Harvard Dataverse is a social science and humanities archive first, and everything else second.

By licence: CC0 1.0 on 77,023 datasets, Custom Terms on 52,648, CC BY 4.0 on 2,402, and everything else in the low thousands or less. Of the 136,150 datasets carrying a licence at all, 57 percent take the CC0 default and 39 percent are bespoke custom terms. Everything in between is a rounding error.

And it is busy. In the 30 days before I looked it served 7,353,662 file downloads and gained 1,143 new datasets. This is a working repository, not a mausoleum.

Some specific things worth knowing are in there:

Election data. The MIT Election Data and Science Lab's County Presidential Election Returns 2000-2024 is at version 20, CC0, with 273,612 views and 86,513 downloads. If you have ever seen a US county-level election map, there is a decent chance it traces back to this file.

Journal replication archives. The political science journals have effectively standardised here. The American Journal of Political Science collection holds 833 datasets, The Journal of Politics holds 1,210. These exist to enforce the journals' data-verification policies, which means the data behind a published article is deposited before the article runs.

An entire archaeological dig. The Leon Levy Expedition to Ashkelon collection holds 28,272 datasets: the raw digital record of an excavation that ran from 1985 to 2016. That is not a summary or a published finding. That is the scanned field record of thirty years of digging, itemised.

The guestbook trap

One more gotcha, and it is the one most likely to break a script.

Some datasets sit behind a guestbook, which asks a downloader to identify themselves. A plain API download of those files does not work:

curl "https://dataverse.harvard.edu/api/access/datafile/13573089"

{"status":"ERROR","message":"You may not download this file without the
required Guestbook response for guestbookID 458."}

The request fails and the message tells you exactly why, which is more courtesy than most services extend. The fix is documented: post a guestbook response to the same endpoint and you get a signed download URL back. The point is that "no account needed" is true for most of Harvard Dataverse and not all of it, and the MEDSL election files, which are among the most-used data on the platform, are in the exception. Write the error handling.

Licensing, and what you are allowed to do

The default license on anything deposited is CC0 1.0, the public domain dedication. Harvard Dataverse's terms define unrestricted submissions as those "published with a default CC0 default public domain dedication waiver agreement." In practice that means you can copy, modify, redistribute and commercialise most of what is in there without asking.

Depositors can opt out and write custom terms, or attach a Data Use Agreement for restricted material. When they do, Harvard is explicit that it takes no responsibility for whether that custom agreement is legally sound. Check the license field on the dataset, not the repository policy, before you build anything commercial on a specific file.

Separately from the license, the Dataverse Community Norms ask downloaders to cite the data and not to attempt re-identification of human subjects. Those norms are not legally binding and say so. They are a professional expectation, and treating them as one is the right call.

The API Terms of Use add two hard limits worth knowing: you may not resell datasets downloaded from the service, and you may not use unreasonable bandwidth, with Harvard as sole judge of what counts as unreasonable.

Sensitive data is refused outright. Everything deposited has to be anonymised, and Harvard does not accept anything classified at HUIT Security Level 3 or 4.

The preservation promise, and its limits

This is the part that separates a repository from a file host, and Harvard puts it in writing.

Files live in an Amazon S3 bucket and are immediately replicated to a second S3 bucket in a different availability zone. After seven days they move to Glacier. Application files and databases are backed up daily to a data centre run by FAS Research Computing at Harvard. Publicly available social science data is additionally replicated by the Data-PASS partners.

The stated commitment is "permanent bit-level preservation of all materials directly deposited in the Harvard Dataverse," along with preserving previous versions, maintaining public access, reviewing risks, and reformatting to avoid format obsolescence. Tabular deposits get normalised into an open .tab format with variable-level XML so the numbers survive the death of whatever proprietary format they arrived in.

Published datasets cannot simply be unpublished. Removal happens only under extreme circumstances and leaves a public tombstone page at the DOI, so a citation never silently dies.

Now the limit. Nowhere in any policy I read is there a succession plan. There is no clause describing what happens to the archive if Harvard stops funding it, no named fallback custodian beyond the Data-PASS replication of the social science subset, and the general terms disclaim all warranties of availability while reserving Harvard's right to remove any upload at any time for any reason.

I do not read that as a red flag. It is the normal posture of a university legal department, and the operational commitments underneath it are stronger than almost anything in the commercial cloud. But "permanent" is a promise made by an institution, not a mechanism, and if your reproducibility plan depends on a file being there in thirty years, keep your own copy too. CC0 means you are allowed to.

What it is good for

A few things I would actually use it for, based on what is in there.

Finding replication packages. Searching for datasets titled "replication data" returns 41,126 results. Political science in particular has made Harvard Dataverse the default place to deposit the code and data behind a published paper. If you are trying to reproduce or extend a result, look here before you email the author.

Publishing data that needs to be citable. If a funder or a journal requires a data availability statement, this satisfies it, gives you a DataCite DOI under the 10.7910 prefix, and costs nothing up to 1 TB. That is a better deal than most institutional repositories offer their own staff.

Versioning something that changes. The COVID dataset at version 67 is the proof of concept. If you maintain a dataset that updates, each release is separately citable, so a paper written against version 12 can still point at exactly version 12.

Storage arbitrage, honestly. The Large Data Services document says this out loud: researchers wanting low-cost long-term storage for smaller datasets are welcome to use the fee-based tiers instead of Google Drive, Dropbox or OneDrive. At $11 per TB per year on tape, that is not a close comparison.

What it is not good for: anything sensitive, anything you need to keep private long term, anything with millions of tiny files on the tape tiers, and anything where you need scripted access to large-data storage.

Fact-check notes and sources

All counts were measured against the live API on 9 August 2026 and will have moved since.

302,139 datasets, 5,436,791 files, 9,332 collections: measured via https://dataverse.harvard.edu/api/search?q=*&type=dataset|file|dataverse&per_page=1
115,999 datasets, 3,406,695 files, 161,092,378 downloads: measured via https://dataverse.harvard.edu/api/info/metrics/datasets|files|downloads
Software version 6.10.1, build iqss-4: /api/info/version
2.5 GB per file, 1 TB total storage, open to non-Harvard researchers: Harvard Dataverse Support, For Researchers
Free curation support to 1.0 TB non-Harvard and 2.5 TB Harvard affiliates: Harvard Dataverse Support, Large Data Support
Storage prices, overhead percentages, consultation rates, file size and file count limits: Harvard Dataverse Repository Large Data Services and Pricing, PDF dated 23 March 2026, linked from the Large Data Support page
Project description, three-level structure, the "bad choice" quotation, founder Gary King, the Virtual Data Center 1997 to 2006, the King 2007 citation, and the funder list: About the Dataverse Project
150 installations across 44 countries: Dataverse installations registry JSON, the file behind the project's installation map
CC0 as the default deposit license, custom terms, and the definition of unrestricted submissions: Harvard Dataverse General Terms of Use
Resale prohibition and the bandwidth clause: Harvard Dataverse API Terms of Use
S3 plus Glacier replication, the seven-day tier move, FAS Research Computing backups, Data-PASS replication, bit-level preservation commitment, and the deaccession tombstone: Harvard Dataverse Preservation Policy
Metrics API caching behaviour and the counting categories: Dataverse Guides, Metrics API
Version 67.1, CC0 license, 12 files, 28,688 views and 12,299 downloads: measured against doi:10.7910/DVN/HIDLTK, US COVID-19 Daily Cases with Basemap, deposited by the Spatial Data Lab
Harvested 186,202 versus Harvard Dataverse 115,937, the subject breakdown and the licence breakdown: the metadataSource, subject_ss and license facets returned by https://dataverse.harvard.edu/api/search?q=*&type=dataset&per_page=1&show_facets=true
7,353,662 downloads and 1,143 new datasets in the past 30 days: /api/info/metrics/downloads/pastDays/30 and /api/info/metrics/datasets/pastDays/30
County Presidential Election Returns 2000-2024 at version 20 with 273,612 views and 86,513 downloads: doi:10.7910/DVN/VOQCHQ, MIT Election Data and Science Lab, read via the dataset and Make Data Count endpoints
AJPS 833 datasets, Journal of Politics 1,210, Leon Levy Expedition to Ashkelon 28,272: Search API with subtree=ajps, subtree=jop and subtree=ashkelonexcavations
The guestbook refusal and its error text: returned by https://dataverse.harvard.edu/api/access/datafile/13573089

The search-versus-metrics discrepancy and the timing-out metrics endpoints are my own observations from working against the API in August 2026, not Harvard statements. Harvard's guides document that metrics count only released local versions, which explains the gap, but I found no page that states the two numbers side by side.

Harvard Dataverse: 302,000 datasets, no account needed, and a 2.5 GB ceiling nobody tells you about