Question

lrcat-data file is too large and very slow to copy, causing very slow backups

Forum|Forum|4 months ago
January 6, 2026
2 replies
578 views

The Lightroom Catalog now has a sidecar file called 'lrcat-data', which I understand stores data calculated from AI operations such as masking and denoise.

Since the denoise feature was updated to store the resulting data in the catalog instead of a DNG file, the size of lrcat-data has ballooned to unreasonable size for many users, myself included. Given we can only expect this to grow, Adobe needs to give us options to better manage this, such as manually or automatically deleting this data from the catalog similar to how previews are handled. If the data is needed again it can be recalculated or loaded from sidecar files (storing it in sidecar files is already supported). I expect this is already in the works.

But there is another issue which I don't think has been raised, which is that the lrcat-data files is structured as some sort of blob archive and, at least for me, is very very slow to copy. You can reproduce this by copying the file on to a fast external SSD, and compare the transfer rate to copying files like large media files or even the lrcat file. The transfer rate is significantly slower for the lrcat-data file, compounded by the fact that it is very large. I believe this is because the file system sees it as a folder with many small files, which have much higher overhead when copying, but regardless of the reason it is very frustrating.

Most importantly this seems to affect Lightroom backups - currently backing up Lightroom takes an unreasonable amount of time for me, and I believe it is due to the slow copying of the lrcat-data file. This should be easily fixable by wrapping the file in a tarball or with any number of other solutions sutiable for backup purposes.

Please fix this, being able to back up our catalog files seamlessly is very important and should be made a priority, even if it takes longer to address the file size issue itself.

[Moved from ‘Bugs’ to ‘Discussions’ by moderator, according to forum rules. This is a real issue, but obviously not a bug.]

macOS

JohanElzenga

Community Expert

The explanation for the slow copy is simple. The .lrcat-data may look like a file, but it is not. It is a so-called 'package'. A 'package' is a folder that MacOS shows like a file and can be double clicked like a file. To open it as a folder you have to right-click on it and choose 'show package contents'. This is not really a Lightroom issue. Packages are used on MacOS for lots of things. Your Lightroom previews and smart previews 'files' are packages as well, but so are almost all MacOS applications. Another example is the Apple Photos library. By the way: on Windows computers the .lrcat-data and previews are folders, because Windows has no packages.

The discussion that the .lrcat-data file balloons if you use AI Denoise (or Super Resolution) a lot is not new, and Adobe should definitely consider redesigning the catalog backup process. The main problem is not copying however, but zipping the backup. If you look at the backup dialog while the process takes place, you'll see that zipping the backup takes the most time by far. That means that you could adopt a strategy where you let Lightroom occasionally make a catalog backup (say once a week), and use a separate backup utility to make daily backups or a backup each time you worked in the catalog. I can clone my entire catalog folder (including 200,000 smart previews and previews) in one third of the time it takes to make a catalog backup using Lightroom! I'll use this until Adobe comes with a new backup system.

P.S. the advantage of a package is that backup utilities can copy only those things inside the package that have changed since the last backup, rather than having to copy the entire 'file'. That is why cloning a catalog folder can be pretty fast. Most backup utilities, including Apple Time Machine, work this way.

-- Johan W. Elzenga

S

Sam31717367fpldAuthor

There are plenty of solutions that would enable faster copying of lrcat-data, they simply need to implement one of them, or allow backing up the catalog without that data. It is absolutely a Lightroom issue, the backup feature is practically unusable at this point, which is completely unacceptable. This is a separate issue from the size of the file.

You can't rely on Time Machine to back up your Lightroom catalog, because if it creates a snapshot when Lightroom is open and the file is being edited there is a very good chance the backup will be in an inconsistant state, and possibly unusable. Even if it makes a snapshot while Lightroom is closed, there is no guarantee that will be the snapshot that is retained - it only keeps hourly backups for 24 hours, if you need to restore after this you'll only have a daily backup up and that might be one that was made with Lightroom open and the catalog file unopened.

Of course I can copy the catalog myself or use a manually triggered back up utility or whatever, I posted this in the hope Adobe would address the issues with the built in backups. Any kind of database backup needs to be done properly and users should be able to rely on the included backup feature to acheive that. DIYing it when you don't know what you're doing is a recipe for data corruption and this is what will happen if users are forced to switch to other backup methods because the built in backups aren't working.

JohanElzenga

Community Expert

You can't rely on Time Machine to back up your Lightroom catalog, because if it creates a snapshot when Lightroom is open and the file is being edited there is a very good chance the backup will be in an inconsistant state, and possibly unusable.

Of course you can rely on Time Machine too (I use a different utility, however), because you can manually start a Time Machine backup any time you want. So close Lightroom, and then start Time Machine. Because that will be the last backup of the Lightroom catalog for that day, that is the one Time Machine will keep.

1 2026-01-06 18-49-25.jpg

-- Johan W. Elzenga

2mittsphotog

Participating Frequently

I'm in full agreement, this should be changed or at least the user should be given the option on where they would like that information stored.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded