Skip to main content
N
nokuru
Participating Frequently
July 27, 2026
Question

Built-in catalog backup takes 14–16 minutes to process 39.7 GiB of nearly incompressible .lrcat-data on SN850 and Optane 900P

  • July 27, 2026
  • 16 replies
  • 128 views

Summary

Lightroom Classic’s built-in catalog backup takes approximately 14–16 minutes to create a 39.1 GiB ZIP containing 39.7 GiB of nearly incompressible .lrcat-data.

I tested the same catalog with two local internal storage destinations:

  • WD_BLACK SN850 1TB, PCIe 4.0 NVMe NAND SSD

  • Intel Optane SSD 900P 280GB, PCIe 3.0 NVMe 3D XPoint

Changing the destination from the SN850 to the Optane 900P reduced the duration by only 105 seconds, or 11.24%. The completed ZIP remained approximately 39.1 GiB.

The main issue is that almost the entire backup consists of .lrcat-data that provides very little compression benefit.

Actual results

WD_BLACK SN850 destination

  • Source catalog: D:\Lightroom\Lightroom Catalog.lrcat

  • Backup destination: same physical WD_BLACK SN850

  • Completed ZIP: 39.112012 GiB

  • Backup folder creation to ZIP last write: 15 minutes 34 seconds

Intel Optane 900P destination

  • Source catalog: same catalog on the WD_BLACK SN850

  • Backup destination: separate Intel Optane SSD 900P

  • Completed ZIP: 39.109688 GiB

  • Backup folder creation to ZIP last write: 13 minutes 49 seconds

The Optane destination was 105 seconds faster, but the total duration was still approximately 14 minutes.

The timings were reconstructed from the NTFS backup-folder creation timestamp and completed ZIP last-write timestamp. They were not measured with a stopwatch.

ZIP content analysis

I inspected the ZIP central directory without extracting the archive.

  • Total uncompressed content: approximately 39.914 GiB

  • Completed ZIP: approximately 39.110 GiB

  • Catalog .lrcat: approximately 0.172 GiB, compressed to approximately 0.078–0.080 GiB

  • .lrcat-data: approximately 39.742 GiB, compressed to approximately 39.032 GiB

  • .blob files: 177

  • Compression reduction for .lrcat-data: approximately 0.710 GiB, or only 1.79%

Approximately 99.8% of the completed backup ZIP is .lrcat-data.

The 6.13 GiB Previews.lrdata folder is not included in the backup and does not account for the result.

During the Optane test, Windows Task Manager showed an initial high-throughput stage reaching approximately 1.5 GB/s, followed by a much longer stage at approximately 60 MB/s with roughly 20% total CPU utilization. These Task Manager values were visual observations rather than an instrumented trace.

Steps to reproduce

  1. Use a Lightroom Classic catalog containing a large .lrcat-data store created through normal AI-assisted editing.

  2. Configure Lightroom Classic to back up the catalog on exit.

  3. Exit Lightroom Classic and create the built-in catalog backup on a local NVMe SSD.

  4. Record the backup-folder creation time, completed ZIP last-write time and final ZIP size.

  5. Inspect the ZIP central directory and compare the compressed and uncompressed sizes of .lrcat and .lrcat-data.

  6. Repeat the backup to another high-performance local drive.

In my tests, both destinations produced substantially the same 39.1 GiB full backup and required approximately 14–16 minutes.

Expected behavior

The built-in catalog backup should remain practical as Lightroom’s persistent AI-edit data grows.

Nearly incompressible AI data should not cause every backup generation to spend this much time processing the complete .lrcat-data store, particularly when a faster destination provides only a small improvement.

Please investigate and correct the built-in backup pipeline so that large, nearly incompressible AI-edit stores do not cause backup duration and required output size to scale this poorly.

The implementation could be determined by Adobe. The required outcome is that unchanged or effectively incompressible AI data should not require the same expensive full processing for every backup generation.

System and workload

  • Lightroom Classic 15.4.1, build 202606201310-b9f148a4

  • Windows 11 Pro 64-bit, build 26200

  • Intel Core i9-13900K

  • 128 GiB RAM

  • NVIDIA GeForce RTX 5090 32GB

  • WD_BLACK SN850 1TB

  • Intel Optane SSD 900P 280GB

  • Catalog integrity check enabled

  • Sony α7R V, 61 MP RAW

  • Approximately 1,000 RAW files per shooting session

  • Recent measured session: 998 ARW files, 67.286 GiB

  • AI-assisted editing is applied across the full shoot

  • The working library already contains several thousand edited photographs and is expected to grow to tens of thousands and beyond

This is a recurring high-resolution portrait workflow, not a one-time catalog import. Splitting every shooting session into a separate catalog would fragment subject management, ratings, keywords, previous sessions and editing history rather than address the scalability of the built-in backup.

Related discussion

A related discussion reports the same general problem with large .lrcat-data backups:

https://community.adobe.com/questions-675/lrcat-data-file-is-too-large-and-very-slow-to-copy-causing-very-slow-backups-1617715

This report adds measured Windows results from two internal NVMe storage technologies, exact ZIP-content analysis and a reproducible high-resolution AI-editing workload.

    16 replies

    JohanElzenga
    Community Expert
    JohanElzengaCommunity Expert
    Community Expert
    July 28, 2026

    I did a bit of extra testing and here’s an interesting observation that many people may not realise. If you use the Adaptive Profile, then Lightroom will create an invisible mask and store that mask in the lrcat-data cache. For my 61 MP Sony A7R V files, that mask is around 1.2MB when stored in an .acr sidecar file, so I think we can safely assume that it adds the same 1.2MB to the cache. That may not sound too much compared to what denoise or superresolution will do, but the adaptive profile is something you add to every single image if you use it in your basic workflow. I started doing that and now have roughly 10,000 images in my catalog where I applied the adaptive profile (my total catalog size is 215,000 images). Not all of these images are massive A7R V files (I use several cameras), but it means this profile is responsible for between 5 and 10 GB of the total 22GB size of this cache… As a result I’m going to reconsider my basic workflow again.

    -- Johan W. Elzenga
      JohanElzenga
      Community Expert
      JohanElzengaCommunity Expert
      Community Expert
      July 27, 2026

      Yes, unfortunately that’s the way it is. If your lrcat-data cache is that big, then 14-16 minutes for zipping the backup is what I would expect. I’ve seen similar total backup times with a cache that is half that size. This has lead me to adopt a new backup strategy. I still have Lightroom set to suggest making a backup on quit, but in practice I only actually let it make a backup perhaps twice a week. All other times that I changed something so a backup is advisable, I run a clone utility that makes a copy of only the catalog file and the cache, so the same as what Lightroom does. The only difference is that this utility does not try to zip the copied files, and it does not make new copies each time but incremental copies, it only copies what is new or has changed. The result is that it only takes perhaps 30 seconds to make this ‘Quick Backup’ as I call it, because most of the cache will not have changed. Next to that I also use the same utility to make a full catalog folder incremental copy, so including previews and smart previews. My catalog folder is about 550GB in size, mainly because I have smart previews and standard size previews of all the 215,000 images. But again, because only new or changed files are copied, this ‘Full Backup’ still only takes perhaps 2 minutes on average.

      -- Johan W. Elzenga
        N
        nokuruAuthor
        Participating Frequently
        July 27, 2026

        Thank you. Your experience helps put my result into context, and I understand why you adopted that backup strategy.

        I also use a Sony α7R V. Its 61 MP RAW workload made my previous PC impractical, so I progressively optimized and upgraded my system to the current Core i9-13900K, 128 GiB RAM, and RTX 5090 32 GB configuration.

        Even with this system, interactive photo-to-photo processing with AI edits is still not as responsive as I would expect. This is one of the main reasons I process approximately 1,000 files per session in batches.

        If this class of workstation still cannot provide a sufficiently responsive workflow with the α7R V, I feel it would be difficult to move to the latest generation of high-resolution cameras. The camera files, AI processing, and catalog backup need to scale as one complete workflow.

        Sameer K
        Community Manager
        Sameer KCommunity Manager
        Community Manager
        July 27, 2026

        Hey, ​@nokuru. Thanks for the detailed benchmarks. I’ve shared this with the team for review.

         

        Thanks!
        Sameer K

          N
          nokuruAuthor
          Participating Frequently
          July 27, 2026

          Thank you for sharing this with the team.

          Please also pass along a closely related performance issue. Even with 61 MP RAW files from the previous-generation Sony α7R V, photo-to-photo navigation during an AI editing workflow is too slow to support efficient image-by-image processing—even on a Core i9-13900K, 128 GiB RAM, and RTX 5090 32 GB workstation.

          This interaction cost is a major reason I batch-apply AI Denoise and AI-based masks to approximately 1,000 files per session. The workstation makes the batch AI processing practical, but the resulting persistent AI data then makes the built-in catalog backup the bottleneck.

          These are two connected scalability issues: interactive high-resolution RAW processing is not sufficiently responsive, while the batch-processing workaround creates an AI data store that the backup system does not handle efficiently.

          I would be happy to provide additional measurements or system information if needed.

          john beardsworth
          Community Expert
          john beardsworthCommunity Expert
          Community Expert
          July 27, 2026

          Are you applying Denoise to every photo? What about other new generative AI-driven processes?

          It’s these that are bulking up the lrcat-data, and you can reduce the problem by being more selective about how/when you apply these new adjustments. I recently helped a guy who had a 436gb lrcat-data file, largely due to applying Denoise unnecessarily to every photo, even though most were low ISO. Having the results of these adjustments in History steps is also a factor. 

          I’ve no doubt that Adobe understands these issues and things are in flux. Remember that not long ago we had to bake a DNG to get Denoise? In Adobe Camera Raw, there are now bulky ACR files instead. And in Lightroom that data has gone into the lrcat-data, and people are reacting to the backup implications. I wouldn’t be surprised to see a smarter way of addressing the problem before too long.

           

          N
          nokuruAuthor
          Participating Frequently
          July 27, 2026

          Yes, I intentionally apply AI Denoise and AI-based masks to every photo. My recurring workflow involves approximately 1,000 61 MP RAW files per session.

          As you probably know, interactively applying these AI processes to files of this size and then moving to the next photo is very slow. That interaction cost is one of the main reasons I process the entire set in a batch instead of deciding photo by photo. Batch processing allows the machine to complete the work without repeatedly blocking the editing workflow.

          This is also why I included my PC specifications. I built the Core i9-13900K, 128 GiB RAM, and RTX 5090 32 GB workstation specifically to make this full-set AI workflow practical. The AI editing workload is manageable; the built-in catalog backup is now the bottleneck.

          I understand that being more selective would reduce .lrcat-data, but that would remove one of the main benefits of this workflow. It is a usage workaround, not a solution to the backup-scaling problem.

          I also attempted the built-in backup to an HDD twice, and neither attempt completed. The SN850 took 15:34, while a separate Optane 900P still took 13:49—only 11.24% faster.

          The issue is not why the 39.7 GiB exists. It is that Lightroom reprocesses and attempts to compress the entire, nearly incompressible store on every backup, including unchanged data. The 436 GB case you mentioned reinforces this scalability concern. Adobe’s backup system needs to scale with the batch AI workflows its software enables.

          john beardsworth
          Community Expert
          john beardsworthCommunity Expert
          Community Expert
          July 27, 2026

          For a while, we/you are probably going to have to get used to it (which doesn’t mean you shouldn’t complain!). And in the recent past we’d just have been backing up big DNGs, and having to think about two files for every photo. 

          AI-based masks are less of a problem, it’s the generative AI stuff that stacks up. So one idea might be to move the batch Denoise to the end of the workflow (updating AI settings before Export/Print etc should be quick). You might apply it just to those you are keeping or using, assuming that’s less than 1000, or only to those where high ISO brings noticeable benefit. Other approaches would help too, even if they’re only ever going to mitigate the problem.

          Firefly Community Gallery
          Adobe Firefly

          Remix with Firefly Community Gallery

          Thousands of free creations to fall in love with and remix in Firefly.

          Explore now
          Terms & ConditionsAccessibility statement
          Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices