Perforce P4 vs. Lore: Architecture Is a Promise, Maturity Is a Track Record 

I have a soft spot for clever version control systems. I started my career in VFX pipelines, I release small open-source projects, indie game dev, and I love making my own custom tools as side projects even though it's hard to maintain them all. So when Epic Games released Lore this year, open-source and written in Rust, my first reaction was curiosity. New and open-source projects have been exploding lately, and I love seeing what’s coming out. 

But interesting and ready to ship are different questions, and conflating them is where most of the Lore vs. Perforce P4 hot takes online go wrong. Lore’s architecture is modern and, in places, excellent. Its maturity is early, by its own team’s account. New projects get to use the latest hot programming languages (I love Rust) and new algorithms, which is always fun, but the Lore team also had to make some architectural decisions early on that form the basis of their system. Some cool stuff, a few that are yet to be proven, and some that I suspect will be hard to work around (more on that later). 

So let me take this on honestly: where Lore is genuinely good, where the conventional wisdom about both products is off, and what it all means if you’re actually trying to ship something. 

P4 vs. Lore: Which Should You Choose? 

Short answer: Choose P4 if you're an established team shipping a large project on firm deadlines. Choose Lore if you have the time to build and maintain your own tooling, and you’re a small team, and you love living on the bleeding edge. 

Choose P4 if: 

• You work on an established team. P4 suits teams that include artists and multiple contributors working on the same project. 
• You're shipping at scale. P4 is built for games, films, and other large productions. 
• You have firm deadlines. P4 offers proven workflows that help teams ship on schedule. 

Choose Lore if: 

• You're a small, new team with strong engineering expertise. Lore works best when your team can handle the technical side. 
• You have time to invest in the system. With Lore, you'll configure the infrastructure, build supporting tools, maintain the system, and contribute improvements upstream. 

P4 vs. Lore at a Glance 

Is Lore Production-Ready? Maturity and Current Use 

This is the first thing to get straight, because it colors everything else. Lore ships as pre-release (0.x); its formats and protocols can still change before 1.0. Epic’s own FAQ says they aren’t expecting studios to replace their existing tools overnight. 

It’s also worth being precise about how much Lore is in use currently. Lore is used by the team building Lore, and maybe some other small teams. There have been no announcements of Lore being tested or used at the scale of a game studio yet.  

At Unreal Fest 2026, Lore’s lead developer was refreshingly direct about this. Asked whether he had a date for when Lore would be production-ready for big projects, he would only offer ‘2027-ish, maybe,’ and noted that the tooling for very large game repositories is still awkward. The open-source release also has no GUI, web client, or code review tooling of its own yet. Epic offers an early desktop client as a binary download, but it isn’t open source yet, and there’s no web client or code review tooling today. 

Perforce P4, by contrast, has decades of heavy use behind it across game dev, animation, film, simulations, chip design, application development, and more. On the maturity axis, this isn’t a close comparison today, which isn’t a knock on Lore so much as a statement of where each product sits in its life. 

What Lore Gets Right 

It’s fully open: MIT-licensed end to end, with every on-disk format and wire protocol publicly specified and versioned. The Perforce P4 server-side software isn’t open source. P4 APIs are public, and people build serious tools on them, Epic’s own Unreal GameSync and RoboMerge are great examples, but you can’t read the server’s guts. With Lore, the whole stack is open. If you want to understand exactly how a modern VCS works, or build a custom backend of your own, it’s a real gift. 

There are a few key differentiators with Lore that I think are interesting: 

• BLAKE3 hashing. Starting fresh let Epic choose a modern hashing algorithm to calculate file fingerprints, and BLAKE3 is fast and parallelizes well on large inputs — a nice advantage over the MD5 Perforce uses in places.  
• Content-addressed, sub-file deduplication. Identical blocks are stored once across the whole repository, and a small edit to a huge file only writes the changed blocks. For a repo full of large binaries with many near-duplicate revisions, that can mean a smaller storage footprint than a whole-file system like Perforce P4. Though this comes with some significant trade-offs and your mileage may vary (see below for more).  
• Offline-first by design. Staging, committing, branching, and diffing all happen locally. It’s a clean model, and something Perforce also embraced recently with the release of P4 One, but in both cases there are some tradeoffs, too. 

My tl;dr: If you’re comfortable setting up all the backend components yourself, you enjoy operating your own infrastructure, you have the time and resources required to maintain an early open-source project, and you want a modern, fully-open foundation to build on, Lore is an appealing project.  

The rest of this piece is about what all this means for real-world projects starting development today or currently in production. 

Storage and Deduplication: Lore's Chunking vs. P4 Delta Transfer 

Lore’s headline storage idea is content-addressed, block-level deduplication. Large files are split into content-defined chunks (via FastCDC), each addressed by its hash, so identical blocks are stored once and a small edit only writes the changed blocks. 

It’s a clever model, and it’s the same technique behind P4’s Delta Transfer, which was released in 2024. Delta Transfer builds a content-defined chunk map, each section’s offset, size, and hash, and sends only the changed sections of a large binary over the wire. The underlying algorithm is the same, but it is applied in a different place. 

P4 uses chunking to move bytes efficiently over the network, and applies it only to large uncompressed binaries, gated by a minimum file size and a difference threshold, falling back to a normal whole-file transfer whenever chunking wouldn’t pay off. Lore uses chunking as the storage format itself, for everything over 256 KiB. That choice is where Lore’s storage footprint advantage comes from, and it’s also where the risk lives. 

It’s worth being concrete about how big that footprint advantage actually is, because it swings hard with your content. When Epic committed the Unreal Engine 5 main repo to Lore as a test, their own design notes record that content-defined chunking deduplicated about 20% of chunks but only about 5% of bytes, not resulting in much space saving. Deduplication shines when you have many near-identical copies of things; on an already-lean codebase it can be modest. Your mileage may vary. 

Then there’s the performance cost, which is a bigger concern for me. In Lore’s implementation, FastCDC targets a 64 KiB average chunk (32 KiB floor, 256 KiB ceiling). A 1 GB file becomes roughly 16,000 chunks; a single 10 GB level or cinematic asset becomes around 160,000 fragments to fetch, decompress and track.  

To materialize a whole file, the client fetches, decompresses, and hash-verifies all of its fragments and reassembles them, so the cost isn’t just disk I/O, but CPU work — decompression plus a BLAKE3 check — and RAM. The fragment index the client maintains grows with the chunk count, so memory and bookkeeping pressure climb as a project scales to millions of fragments. (A project above just 64 GB is likely to hit 1 million chunks, based on those numbers.)  

Content-defined chunking as a storage format is well-proven in backup tools like restic and Kopia, but those aren’t latency-sensitive, interactive workloads, and they usually do their deduplication offline in the background because it can be slow. What the performance looks like when team members sync a project with many millions of fragments, is the thing no studio has actually measured on Lore yet. It may turn out fine with powerful enough hardware, but it’s simply unproven. 

That cost isn’t hypothetical even in the surgical case. P4’s own Delta Transfer documentation notes that computing chunk maps “can take more time on larger files” and “could use more CPU,” and that content-defined chunking “pressures archive I/O performance.” Applying that everywhere, rather than only where it pays, multiplies it. 

In fairness, P4’s model carries its own trade-off in the other direction: storing whole files uses more disk than Lore’s sub-file dedup. Perforce P4 compresses files by default, which is more effective on some files than others, but doesn’t do any deduplication. P4 chose predictable read performance over maximal storage savings, because an artist waiting on a file to sync is a worse outcome than buying another disk. Storage isn’t free, and server compute, RAM and wait time isn’t either, so either model makes different trade-offs. 

Sparse Sync and Offline Work in P4 vs Lore 

Two more capabilities often listed as Lore advantages deserve a closer look, because they’re less unique than they sound. 

Sparse by default. Lore and Perforce P4 both only fetch the files you actually use, so your local footprint tracks your working set, not the whole repo. Selective sync is a difference against Git-based version control systems like GitHub, GitLab, and BitBucket, not against Perforce. P4 has always let you sync only the depot paths you need. On Windows P4 goes further with Virtual File Sync (P4VFS), which syncs only file metadata up front and hydrates the full content on demand the moment a file is opened, that kind of virtual file system is in progress for Lore, but not usable yet. 

Offline work. Lore bakes offline operation into everything, which is a clean design. Perforce P4 supports offline workflows through DVCS (distributed versioning), but it doesn’t default to that on its own. P4 One, Perforce’s new versioning client does support native offline versioning for local work before submitting to a P4 Server.  

However, with any version control, I always warn people that working offline on unmergeable binary files carries an unavoidable risk of two people editing the same asset at the same time. The only thing that truly prevents that is a connection to a central server that can hand out an exclusive lock. So just because you can work offline doesn’t mean you should. 

File Locking for Binary Assets: Enforced vs. Advisory 

If you’re building a game, creating a 3D model or circuit layout, or working on VFX or animations, file locking is essential, because binary assets (or non-text based files) can’t be merged. Two people editing the same file means someone’s work is just lost, and there is no way to merge them, so it's always better to catch it early by blocking the work rather than finding out AFTER you’ve done a full day of work. 

Perforce P4 uses server-enforced exclusive checkout: the server refuses the second checkout. Lore’s locking is informational rather than blocking. It warns you a file is in use but doesn’t actually stop the overwrite (enforced locking is on the roadmap). 

There’s a second, subtler issue: locking across branches. It’s a challenge both systems share, and it requires some custom tooling to solve. Epic’s own built-in source control in Unreal Editor already offers an option to check for locks on other branches when you’re working against Perforce. Lore doesn’t have that yet, but presumably it would work the same.  

In game development, it is common practice to do less branching than in pure code software development, for exactly this reason. That same difference shows how reviews are done. (See the section on shelving below for more.) 

Version History: Immutable (P4) vs. Rewritable (Lore) 

Lore’s history is built like Git: branches are moving pointers over a directed acyclic graph, and history can be rewritten by users. Commit-amend and cherry-pick ship today; rebase and squash are described in its data model. When history is rewritten, Lore writes fresh revisions and moves the branch pointer to them, and the originals become unreachable from that branch.  

In Lore’s architecture docs, it clarifies a squashed chain is “no longer reachable from any branch latest pointer.” There’s also a lore file obliterate command to purge a file or fragment outright.  

That’s the familiar Git trade-off: flexible history, but the recorded history can be reshaped causing merge challenges, and the provenance of how a file evolved can be lost. Git-style cherry-pick/merge-cleanup is not for the faint of heart and often blocks non-engineers until they can get someone to help them. This is an architectural decision I question, and it’s a design choice, not a maturity gap. 

Perforce takes the opposite approach by design. A submitted changelist is immutable and append-only: every revision of every file is recorded permanently and stays auditable, so you can always reconstruct who changed what, based on which source, when it changed, and in what order. (Perforce has an obliterate too, but it’s a deliberate, privileged administrative action, not part of a normal developer’s day.) 

Back when I was first learning to use version control, Git’s “flexibility” with the truth of file history never felt good to me, but neither model is universally right; rewritable history can be convenient for tidying a feature branch before human review, at the cost of losing an accurate history.  

But for studios using AI coding agents, facing compliance obligations or legal reviews of asset lineage, or needing to prove ownership of their IP, especially as AI-generated content becomes more common, permanent history is a real advantage. It also changes how merges behave, which matters more than ever now that AI agents are committing alongside people.  

For a deep dive on how history models affect code merging, check out our recent post on P4 versus Git for AI coding agents. 

Submit Model: Per-File vs. Whole-Branch Push 

This one is another core architectural decision with real day-to-day consequences, and it’s worth getting the mechanics exactly right. 

In Lore, like Git, a branch is a single moving pointer, and a push advances that pointer with a compare-and-swap: the push succeeds only if the branch tip is still exactly where you based your work. Your commits are local, so you can commit all day offline; the contention happens at push. By default, if anyone has pushed anything on that branch since your last pull, even on unrelated files, your push is rejected, and you have to pull all their changes in and try again. Lore can optionally have the server merge your push for you, which works when the changes don’t touch the same content; if they do, you’re back to syncing and merging locally. 

Perforce submits are per-file: only the specific files you’re submitting need to be current. Someone else’s unrelated submit doesn’t block yours, and on an exclusive-locked binary your checkout already holds the lock, so nobody can update it ahead of you. The difference bites exactly when you can least afford it—at crunch, when the whole team is racing to land final changes. On Lore you can end up in a catch-up loop: pull everyone’s work, try to push, get beaten to the branch tip, pull again, repeat. 

Scale and Track Record 

When it comes to scale and reliability, Perforce has the clear advantage due to many long-term customers; several who have thousands of users, create tens of thousands of submits every day, and store petabytes of data. Perforce P4 runs federated architecture today, commit, edge, replica, and proxy servers, so a globally distributed team gets local performance wherever they sit, while the organization gets failover, disaster recovery, and backups protecting the data the whole business depends on.  

Lore may get there eventually, but it doesn’t have that level of stability or trust yet. 

Ecosystem, APIs, and Shelving 

Lore is API-first, fully open, and a solid foundation. Their API is comprehensive and easy to adapt if you’re prepared to build your own tooling. This is genuinely cool for those (like me) who like to tinker and customize. The flip side is that it is build-it-yourself today: the integrations, clients, and review tools a studio leans on are things you’d be coding yourself or waiting for someone else to do. 

One workflow gap is worth spelling out, because teams hit it fast: shelving. In Perforce, you can shelve a pending changelist to share work for review, or to kick off server-side builds and tests on your change before it’s ever submitted. That pre-submit safety net— run CI, get a review, catch a crash early, validate changes—happens without committing anything to the mainline and without spinning up extra branches. Lore has no shelving; the nearest path is to commit to a branch, push it, and open a change request, which means more branch management and brings back the cross-branch questions from above. Shelving keeps “share and validate before you land” simple, and that simplicity does a lot of quiet work on a busy team. Even Lore fans agree that not having shelves is an issue. 

Is Lore Free? Cost and Support Compared 

Short answer: Yes, Lore is free software, but running it in production is not free. Teams that deploy Lore pay for the infrastructure, engineering time, and training needed to operate it. 

What Does a Production Lore Deployment Cost? 

Running Lore for a team means standing up and operating several components yourself: 

• Durable object storage. Lore needs reliable storage for your project files. 
• A separate metadata store. Lore keeps metadata in its own dedicated store. 
• Caching tiers. Lore relies on caching layers you'll need to run and maintain. 
• The Lore server. Your team hosts it, or pays a third party. 

Beyond infrastructure, Lore also requires: 

• Building integrations. You'll need to create the integrations your workflow depends on. 
• Training your team. Your contributors will need time to learn the system. 
• Managing pre-1.0 risk. Lore hasn't reached version 1.0, so breaking changes may require extra work. 

It also helps to be concrete about what a paid product includes. Perforce offers a free, fully-featured self-hosted tier for up to 5 users and 20 workspaces. Beyond that, P4 Cloud runs about $39/user/month, and that price isn’t just the software. It covers backups, updates, and real support with real people to contact when a production is on the line. 

Support and backing 

Epic’s involvement is the strongest argument for Lore’s long-term prospects, and I don’t want to undersell it. The open question is what “backed by Epic” means for support. For most of Epic’s products, support looks like GitHub issues and community channels unless you’re an enterprise licensee.  

Whether Lore gets a genuine support commitment beyond that, an SLA, someone to escalate a production-down incident to, is something we don’t know yet, and I do not expect from them. For a studio relying on version control for a product they plan to ship, that alone could be a dealbreaker. 

When to Use P4 and When Lore Makes Sense 

For most teams shipping a game or a film at scale today, with real art teams and deadlines, Perforce is the choice that fits: enforced locking, permanent provenance, a per-file submit model that holds up at crunch, shelving, broad engine integrations, proven scale, and someone to call when it matters.  

If you’re a smaller team with strong engineers, and the willingness and time to tinker with the source code, the honest answer is more open: a fully-open, self-hosted system like Lore is a reasonable thing to evaluate. For a team willing to get into the weeds—standing up the tiers, building the tooling, maintaining it yourself, contributing PR’s back to it— Lore’s storage efficiency and offline-first model are real attractions, and that hands-on cost can be worth it. Just go in clear-eyed that the work is the price. (Perforce’s free 5-user tier is a fully-featured place to start either way.)  

Lore is a cool project, and I mean that. The architecture is modern, the open spec is admirable, and the storage and hashing ideas are the kind of thing I enjoy reading about and playing with. Teams here at Perforce have been kicking the tires on it, and I’ll keep poking at the source myself. But my own game projects will keep living in my self-hosted Perforce instance, not because Lore isn’t interesting, but because shipping and tinkering are different jobs, and right now Perforce is the one built for shipping. 

Compare P4 with Lore for Free 

See how P4 fits your team’s workflow, scale, and production needs. Get started free with up to 5 users and 20 workspaces. 

Try P4 Free 

Figures and capabilities reflect public information and Perforce product details as of  as of October 2026 (Lore v0.11.0). Lore details draw on Epic’s public documentation and Lore’s lead developer’s Unreal Fest 2026 talk (paraphrased).