Last week Epic announced Lore version control and released the source code via MIT license on GitHub. The initial reaction was insane. The repository gathered more than 6,000 stars in one week. Single developers and studios are interested in the promises Lore is making — scaling up to repositories with hundreds of terabytes without any overhead. Because of that, we also started the implementation of a dedicated Lore client for art assets.

FOSS is great and all, but we wanted to know if it's any better or faster than the current options such as Git and Perforce. So we embarked on a quest to find the answer. Spoiler upfront: it performs great, but came with one big surprise.

We don't claim this test to be an absolute truth, but we did a few things to make the comparison as fair as possible. Please keep in mind that the data gathered in this article is the result of a few runs and results may vary, but this should be a good ballpark.

Context

The goal of the test was to run an initial commit of the Unreal Engine source code with an example project included. We ran the same process using Lore (with and without S3 storage), Perforce, and Git.

Our Setup

Hardware

• Internet: 920 Mbps download / 790 Mbps upload (measured via fast.com)
• Disk: Samsung NVMe M.2 SSD (Read: 7,450 MB/s | Write: 6,900 MB/s)

Software

• Git 2.54.0 with Git LFS 3.7.1 and Gitea 1.26.4
• Perforce 2026.1
• Lore 0.8.3

Note: We used the version of Lore published at the time of the official announcement. Depending on when you read this, newer versions may exist that could influence these results.

The Server

We used a classic EC2 instance in a European region to stay close to our office.

• Region: AWS eu-central-1
• Instance type: c6i.2xlarge
• Latency: ping -n 20 <ip> → Min 32ms / Max 33ms / Avg 32ms

The Repository

An Unreal Engine 5.8 clone from GitHub (excluding the .git folder, with Setup.bat executed): https://github.com/EpicGames/UnrealEngine/tree/5.8

• Files: 392,559
• Total size: 63.5 GB

What Are We Testing?

One specific Lore feature caught our attention first: the S3 backend. Extending server storage and managing it via command line is painful, and disks can fill up fast — so an infinitely scalable solution like S3 seems like the perfect fix.

That's why we're running two tests for Lore: one with S3 storage and one with EBS storage. EBS means the internal disk provided by the EC2 instance. Since both Git and Perforce write to EBS, that's the accurate apples-to-apples comparison — but we had to try S3 as well.

Results

One thing to note first: unlike Git, Lore uploads files on commit, not on push. In Lore, push is more of a publishing step — the files are already on the server by then.

Two takeaways at first glance:

• Lore (EBS) is 15x faster than the next best option
• Lore (S3) lags a full hour behind

We tested both with DynamoDB running on AWS and locally, but S3 appears to throttle requests after the first ~50k shards. Not great — but likely fixable with the right AWS/S3 configuration.

Lore performs great — but only on EBS

Lore shines when storing files on an internal drive, which covers the typical self-hosted studio setup. The problem is that drives fill up, so you eventually need to extend storage.

S3 is the obvious answer for scalable, cloud-hosted environments — but it disappoints. We never managed to complete a full initial commit regardless of how we tweaked the settings. On top of that, the failed attempts generated significant unexpected AWS costs.

We tried raising DynamoDB connections from 100 to 5,000 to address throttling, and splitting the commit into smaller chunks did work — but that wasn't the point of the test. A complete initial commit in one go simply wasn't achievable.

Hopefully a future Lore update or better documentation will let us revisit this.

Half of our $300 bill came purely from Lore's S3 uploads

Even if speed doesn't improve, we're happy with the results when ignoring the S3 approach. The push failed at the end, and the AWS bill was a surprise: roughly $300 for the entire experiment. Not because of the data volume, but because Lore's chunking splits files into pieces that each require a separate S3 API request — and those add up fast.

We hope this gets addressed in a future release.

The Lore S3 upload itself cost $144.78. The remaining ~$155 covers other AWS services, taxes, and the combined cost of running Lore (EBS), Git, and Perforce.

Compression

After uploading, Lore still comes out on top when it comes to compressed repository size:

Lore's chunking mechanism works exceptionally well when storing compressed files — especially when committing multiple versions of the same file.

Download

Even when downloading files via clone, Lore excels. Unfortunately, we never managed to successfully create a commit using Lore with S3 storage, so we couldn't test a full clone with that configuration.

How we ran the tests

A quick technical explanation of our parameters.

Lore (S3)

Install via: curl -fsSL <https://raw.githubusercontent.com/EpicGames/lore/main/scripts/install.sh> | bash -s -- --server

local.toml

[immutable_store]
mode = "aws"

[mutable_store]
mode = "aws"

[lock_store]
mode = "aws"

[plugins.aws.immutable_store]
s3_bucket                = "**bucket-id**"
s3_region                = "**bucket-region**"
dynamodb_fragments_table = "**db-table-fragments**"
dynamodb_metadata_table  = "**db-table-meta**"
dynamodb_region          = "**db-region**"

[plugins.aws.mutable_store]
dynamodb_table  = "**db-table-mutable**"
dynamodb_region = "**db-region**"

[plugins.aws.lock_store]
dynamodb_table  = "**db-table-locks**"
dynamodb_region = "**db-region**"

Fair warning if you want to try this: pushing the repo generated lots of S3 Put requests, which resulted in the elevated costs.

[immutable_store.local]
path = "/data/lore"

[mutable_store.local]
path = "/data/lore"

Perforce

Running via Docker using this image: https://github.com/hawkmoth-studio/perforce-docker

We also used the typemap from this article: https://dev.epicgames.com/documentation/unreal-engine/using-perforce-as-source-control-for-unreal-engine

Git

Running via Docker using this image: https://github.com/go-gitea/gitea

What we did here is unconventional and we don't advocate for it. It's possible, but in most cases teams are better served by forking the official UE repo and working from there.

However, to make this comparison fair, we did a few things:

• All files from the git clone of the repo were submitted as plain files
• All files from Setup.bat were marked as LFS and submitted as such

To achieve this, we deleted the .gitignore and used the following gitattributes

Again, don't do this at home — but we needed to ensure fair compression. In practice, always use a .gitignore.

Conclusion

We're looking at a non-production-ready version of Lore, and the EBS storage results look really promising. We still need to evaluate how Lore performs over time as the repository grows. Based on its design, it offers cheap branching and commit count shouldn't affect performance at all — that needs follow-up testing.

It definitely looks like the ultimate solution for large, binary-heavy projects.