Research · the engine and the platform
GitHub is the best place in the world for text. It was never built for bytes.
Not a takedown. Git is a content-addressed store for source code and it is superb at that. The question is what happens when the files are a 4GB level, a 900MB PSD or a folder of camera raws, and the answer has been the same for fifteen years: a wall, then a workaround that the people using it call a hack.
Published limits
The walls are documented. They are the shape of the design.
None of these are bugs and none of them are going to move, because they follow from what git is. Git stores every version of every file as a whole object and expects to hand you all of it. That is exactly the right design for source code, where a file is a few kilobytes of text and the whole history of a large project fits in a few hundred megabytes. It is the wrong design for a texture.
The escape hatch
Git LFS is the answer, and three things about it are structural.
It stores every version whole. LFS moves the big file out of the repository and replaces it with a pointer, which solves the clone size problem and solves nothing about history. Change one megabyte inside a one gigabyte file and LFS keeps a second gigabyte. Ten revisions of a level is ten copies of a level.
Popularity bills the owner. Every LFS download is charged to the repository owner at $0.0875 per GiB, and that includes forks, CI runners and anyone who cloned out of curiosity. An asset-heavy repository that gets popular becomes a liability to the person who published it, which is a strange property for a platform built on public sharing.
It is a one-way door. LFS objects keep counting against the quota after a history rewrite. The documented way to reclaim the space is to delete the repository.
The community verdict has been stable for years and is not ours to soften: the standing description is a really really bad gross hack. It is still the default recommendation, because on GitHub there is nothing else.
The receipt
The biggest GitHub-for-X ever built left Git LFS, and published the numbers.
Hugging Face is the clearest proof that the git interface wins adoption: it took git's model, pointed it at model weights, and became the hub for an entire field. Then it hit the same wall, and between January and July 2025 it migrated more than 500,000 repositories and over 20 petabytes off Git LFS onto Xet, its own storage layer built on content-defined chunking at roughly a 64KB grain with deduplication across repositories.
Their published measurements: 30% to 85% deduplication across checkpoints, and 2x to 3x faster transfers. The conclusion they reached is the one this whole article is about. Git's interface is worth keeping. Git's storage cannot carry big binaries, and no amount of pointer files changes that.
The technique is not exotic and it is not ours. FastCDC was published in 2016 and has been proven in backup tools for a decade. What is new is applying it to ordinary version control for everyone else, rather than to one vertical at hub scale.
The engine underneath
A version is a list of chunks, so only the changed ones are new.
Lore is the open-source version engine Epic Games built for Fortnite, MIT licensed, and it is what Interlinked hosts. It keeps a project as content-addressed chunks, and a version is a list of references to them. Save a one megabyte edit inside a one gigabyte file and the store grows by about 1.1MB, not 1GB. Four thousand untouched assets beside it move zero bytes.
That turns the promise around. Keeping every version is a near-free thing to offer when history costs deltas rather than copies, which is why Dropbox caps version history at 30 or 180 days and we do not: for them each version is a copy, and copies cost money. Storage is billed after deduplication here, so you pay for genuinely new bytes and not for the same texture stored eleven times.
The honest limit, stated because every platform shares it: re-encoded output defeats chunking. A re-exported video or a rezipped build changes every byte, and a new version really is a full copy. That is true on GitHub, on Dropbox, on Perforce and here.
Use both
Three of these rows are not our job, and we are not pretending otherwise.
We are not a GitHub replacement and there is no version of this argument where you should move your source code. Keep it there. The lane is the one GitHub structurally cannot serve: the files it rejects, the history it stores whole, and the person you need to send a version to who is never going to make an account.
The part nobody prices
You cannot download a folder from the GitHub web UI.
It sounds like a small thing and it is the whole difference in practice. On GitHub, everything that is not a clone requires an account, and a fair amount of it requires a client. A link here opens the project in a browser, with its history, on a phone, for someone who has installed nothing and signed up for nothing. The files stay whole on your disk at the same time, and everything except push and pull keeps working with the network off.
That is also why the per-seat question stops mattering. The people who only need to look at the work were never going to be seats, and on every platform that charges for them, they were.
The short version
Keep GitHub for the code. Put the heavy things where they fit.
$5.99 per 100GB for storage and transfer, no seats at any team size, unlimited projects. The desktop app, whole-machine search and the ifile CLI are free forever on every machine you own. If you want the engine comparison in detail rather than the platform one, there are thirteen measured differences between Git with LFS and Lore on the engine page.