unsplash/datasets: Two Tiers, Two Licences, One Photo Corpus

The problem is a labelled photo corpus, not a photo library

Anyone can pull images from a stock site. What is hard to assemble is a corpus where each image carries structured metadata and where the query log that surfaced it is also available. The Unsplash Dataset is aimed at that second problem. The README describes it as data sourced from hundreds of millions of searches, contributed by over 415,000 photographers, and it splits the material into three kinds of record: photos, keywords, and searches. The Lite tier holds 25k photos, 30k keywords and 1M searches. The Full tier holds 7.4M+ photos, 1.6M keywords and over 160M searches. The audience is stated plainly: research and machine learning, and the README asks for attribution in the form Unsplash Lite Dataset 1.4.0 or Unsplash Full Dataset 1.4.0 with a link to unsplash.com/data. If your task is training a retrieval model, studying how people describe images, or building a keyword-to-photo index, the search table is the part you cannot get from a scrape.

Lite versus Full is a licence boundary, not a size setting

The two tiers share the same fields, according to the README, which says the Lite dataset contains all of the same fields as the Full dataset and is limited to roughly 25,000 photos. The difference that decides your choice is the terms. Lite is offered for commercial and noncommercial usage provided you abide by TERMS.md. Full is available for non-commercial usage and also points at TERMS.md. So a team building a commercial product can start on Lite and cannot simply scale up to Full by downloading more data. Size differs too, and the README gives the numbers: Lite is about 700MB compressed and about 1GB raw, while Full is about 20GB compressed and about 80GB raw. The Full tier is not a direct download. The README directs you to unsplash.com/data to request access, which means an approval step sits between you and the data. Budget for that delay if it is on a project timeline.

What the repository actually contains: notebooks, docs and loader recipes

The primary language is Jupyter Notebook, and the how-to directory is where the loading work lives. The README lists three entry points: load the dataset in a PostgreSQL database, load the dataset in a Python environment, and a page describing how to submit an example doc. The complete list of tables and fields is kept in DOCS.md rather than in the README, so the README alone will not tell you the column names. That split is sensible for a dataset that changes shape between versions, but it means you should read DOCS.md before writing any ingestion code. The repository is not archived and the most recent release listed is 1.4.1 from 2026-06-26, with 1.4.0 two weeks earlier and 1.3.0 before that in April 2025. The README states that releases are semantically versioned and that updates add new fields and new images.

Getting it running: download, then pick a loader

Lite is a direct download from unsplash.com/data/lite/latest. Full requires a request through unsplash.com/data. Once you have the archive, the repository gives you two documented paths. For PostgreSQL, the how-to/psql directory holds the instructions for loading the tables into a database, which suits anyone who wants to join photos against keywords and searches with SQL. For Python, how-to/python covers loading into a Python environment, the path you want if the next step is a dataframe or a training pipeline. The repository also invites example docs through how-to/README.md, which is worth knowing if your loader differs from the two published ones. There is no published pip package and no single install command in the material provided; the how-to directories are the interface, and the field names come from DOCS.md. I have not run either loader, so treat the directory contents as the source of truth rather than any summary here.

The redistribution clause is the constraint that shapes real projects

The README is explicit that the dataset is made available for research purposes and cannot be used to redistribute the images contained within, linking to TERMS.md, and it points anyone who wants to use the Unsplash library in a product at the Unsplash API instead. That single sentence rules out a whole class of obvious ideas. You cannot ship a search demo that serves the photos. You cannot build a wallpaper app on the Full tier. You can train on the images, study the metadata, and publish findings, subject to the terms. The licence identifier is not stated in the repository metadata, so the operative document is TERMS.md, and it is worth reading in full rather than inferring permissions from the README's summary. This is a description of what the repository says, not legal advice; if the distinction between training and redistribution decides your product, get a lawyer to read TERMS.md.

Where the dataset is the wrong tool

If you need images in a shipping product, this is the wrong repository and the README says so, directing you to the Unsplash API. If you need a commercially usable corpus at Full scale, the licence does not allow it, and no amount of engineering changes that. There is a subtler failure mode: the Full tier is 80GB raw, so the download, decompression and indexing cost lands before you have answered any research question, and the access request adds a wait on top. A team that only needs a few thousand labelled photos for a prototype is better served by Lite, which carries the same fields at 1GB raw. And if your work depends on a field that was added in a recent release, pin your attribution and your code to that version, because the README ties new fields to new releases and version numbers appear in the citation format itself.

The alternative is the API, and the difference is what you receive

The README names the Unsplash API as the route for using the library in a product. The two approaches hand you different things. The dataset gives you bulk tables: photos, keywords and searches, delivered as an archive you load into PostgreSQL or Python, with no per-request quota and no live service in the loop, but with a licence that forbids redistributing the images. The API gives you a way to serve Unsplash images inside a product, which is exactly what the dataset forbids, but it is a request-based service rather than a corpus you own, and it is not described in this repository beyond the single link. Choose by asking whether you need to analyse the corpus offline or display photos to users. Those are different jobs and the README routes them to different places.

Version churn and what it costs to stay current

The release history in the material shows 1.3.0 in April 2025, then 1.4.0 and 1.4.1 in June 2026. That is a slow cadence, which keeps upgrade work low, but each release can add fields and images, and the README says attribution should name the version, for example Unsplash Lite Dataset 1.4.0. If you publish results, record the version you trained on or your numbers will not be reproducible against a later download. If you load into PostgreSQL, a new release means re-importing the affected tables, and at Full scale that is an 80GB raw operation, not a patch. The repository's own advice is to open an issue to report problems or request fields, which is the practical channel if the schema is missing something you need. There is no separate maintenance burden beyond that: no server to run, no dependency tree to patch, just a version number to track and a terms document that governs what you may do with the result.

Editorial conclusion

Adopt the Lite dataset if you need a commercially usable photo corpus with keyword and search tables and can live with roughly 25,000 photos; request the Full dataset only if your work is genuinely non-commercial and you can store around 80 GB raw. Neither tier lets you redistribute the images, so if your product serves photos to end users, go to the Unsplash API instead. Before committing, open TERMS.md and DOCS.md and confirm two things: that your intended use falls inside the tier you downloaded, and that the fields you plan to train on exist in the release you have, since the README states that new fields arrive with new versions.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. unsplash/datasets on GitHub