Lightroom Classic 15.5.1 — Technical Performance Report

Subject: Progressive Develop performance degradation, unusually large .lrcat-data, and possible memory/resource-management problems

Application: Adobe Lightroom Classic 15.5.1
Operating System: Windows 11
CPU: AMD Ryzen 7 8700G
GPU: NVIDIA GeForce RTX 4060 Ti 8 GB
Catalog: Approximately 20,000 photographs
Camera: Sony α1 II, 50.1 MP RAW files
Typical RAW file size: Approximately 60 MB

Executive Summary

I am reporting a progressive performance problem in Lightroom Classic 15.5.1 that I believe warrants investigation as a potential application resource-management problem rather than simply a hardware-performance limitation.

The principal symptoms are:

1. Develop responsiveness progressively deteriorates during extended Lightroom sessions.

2. CPU utilization can rise substantially simply from navigating from one photograph to another, even when no processing operation has been initiated.

3. GPU utilization is often very low during the periods when Develop responsiveness is poor.

4. Restarting Lightroom restores responsiveness temporarily, but the problem returns after extended use.

5. Lightroom can remain active as a Windows background process for several minutes after being closed.

6. The .lrcat-data associated with my principal catalog has grown to approximately 85 GB.

7. Catalog optimization does not prevent the performance degradation from returning.

8. A smaller test catalog has demonstrated similar progressive Develop behavior despite having far fewer photographs.

9. Denoise itself appears to utilize the GPU effectively and consistently, suggesting that the hardware is capable of performing the actual AI processing efficiently.

I am not claiming that .lrcat-data growth has been proven to be the direct cause of the Develop slowdown. However, the combination of extremely large application data, progressive resource consumption, and declining responsiveness suggests that Lightroom's long-session resource and data management deserves investigation.

User Background

I am an instructor at the Osher Lifelong Learning Institute at Furman University, where I have taught Adobe Lightroom Classic for approximately ten years. This gives me an opportunity to observe Lightroom's behavior across a broad range of users and computer systems.

The concerns described in this report are not limited to my own system. My students have also expressed similar concerns about Lightroom Classic's increasing resource requirements, responsiveness, and performance during extended workflows.

I therefore believe this issue merits consideration not simply as an isolated configuration or hardware problem, but as a potential broader usability and resource-management issue affecting experienced Lightroom Classic users.

My Hardware Is Not Obviously the Limiting Factor

My system is:

• Ryzen 7 8700G

• RTX 4060 Ti 8 GB

• 32 GB system RAM

• Windows 11

• Lightroom Classic 15.5.1

Denoise processing of a single Sony α1 II RAW file takes approximately 20–24 seconds.

During Denoise, the RTX 4060 Ti typically reaches approximately 85–95% GPU utilization, demonstrating that Lightroom is capable of making effective use of the available GPU when performing this workload.

Importantly, the Develop slowdown I am reporting is different.

When Develop becomes sluggish, GPU utilization can remain very low while CPU utilization increases substantially. Moving rapidly from one photograph to another can cause Lightroom's CPU utilization to rise to approximately 50%, then gradually fall back toward idle after approximately two minutes.

Therefore, simply recommending a faster GPU does not appear to address the behavior I am experiencing.

Progressive Develop Slowdown

The problem is most apparent after Lightroom has been used for an extended period.

Initially, moving from image to image in Develop is responsive. After processing and navigating through many photographs, however, responsiveness progressively deteriorates.

Symptoms have included:

• Several-second delays when changing photographs.

• Delayed response from Develop controls such as Exposure.

• CPU utilization increasing simply from moving through photographs.

• Performance remaining degraded even after Lightroom has been left idle for an extended period.

• Performance being temporarily restored by restarting Lightroom.

This behavior has also appeared in a smaller catalog, so the issue does not appear to require a 20,000-photo catalog to reproduce.

.lrcat-data Size

The most unusual aspect of my primary catalog is the size of its .lrcat-data data.

The catalog contains approximately 20,000 photographs, and the .lrcat-data file is approximately:

85 GB

This is a very substantial amount of application data relative to the number of photographs.

Adobe documentation confirms that .lrcat-data contains important information associated with photographs and edits, including AI-related information. Therefore, I understand that this is not simply disposable cache data.

My concern is not simply that the file is large. My concern is whether Lightroom's architecture allows AI-related data to accumulate indefinitely without sufficiently effective reclamation when the underlying photographs or processing history are no longer relevant.

Investigation of the .blob Structure

I investigated the contents of .lrcat-data using two test catalogs.

A newly created catalog containing only one photograph contained a .blob file of approximately:

27,319 KB

An older test catalog, which had previously been used with approximately 1,000 photographs but had subsequently been reduced to one photograph, also contained a .blob of approximately:

27,319 KB

The filenames were different because they are sequentially numbered:

• Older catalog: 000336.blob — 27,319 KB

• New catalog: 000010.blob — 27,319 KB

This demonstrates that approximately 27 MB is apparently a baseline component of Lightroom's .lrcat-data structure and should not automatically be interpreted as accumulated historical AI data.

However, examination of the principal 20,000-photo catalog revealed a dramatically different structure.

The .blob files include:

• 033042.blob — approximately 266,299 KB

• Sequential .blob files continuing through

• 033548.blob — approximately 58,127 KB

The files between these entries are generally around 267,000 KB each.

This means the principal catalog contains hundreds of very large sequential blob files.

I have not assumed that each blob corresponds to one Denoise operation or one photograph. I would like Adobe engineering to clarify precisely what these blobs represent and how Lightroom manages, reclaims, and compacts them.

Denoise Workload

My photographic workflow is also relevant.

I use a Sony α1 II capable of shooting at up to 30 frames per second. I frequently shoot bursts and may discard approximately 95% of the resulting images during culling.

Approximately 25% of the photographs in my main catalog have been Denoised, by my estimate.

This creates an unusually high-volume workflow in which Lightroom may process very large numbers of photographs that ultimately do not remain in the catalog.

That raises an important architectural question:

Does Lightroom permanently retain AI-processing data for photographs that are subsequently rejected, deleted, or otherwise no longer relevant to the catalog?

If so, what mechanism does Lightroom provide for safely reclaiming that storage?

Catalog Optimization

I routinely optimize the catalog.

I also back up the catalog whenever Lightroom exits, with the backup stored on an SSD.

The optimization and backup process can take approximately 35 – 50 minutes.

Optimization does not permanently resolve the progressive Develop-performance problem. The performance degradation returns after Lightroom has again been used for an extended period.

This suggests that catalog optimization is not addressing whatever resource-management problem is occurring during normal operation.

Shutdown Behavior

Another observation is that Lightroom does not always terminate immediately after being closed.

After an extended working session, Lightroom.exe can remain visible as a Windows background process for several minutes after the Lightroom interface has closed.

The amount of time appears to increase depending on how much work Lightroom has performed during the session.

A newer catalog initially closes quickly, while the same catalog can take longer to close after several hours of work.

This suggests that Lightroom may be performing substantial cleanup, database work, or data-management operations during shutdown.

Why I Believe This Deserves Investigation

I understand that modern Lightroom features require significantly more processing and storage resources than earlier versions.

I also understand that a 50-megapixel camera and AI processing place substantial demands on a computer.

My concern is different:

The system appears capable of performing the individual computational tasks, but Lightroom's responsiveness deteriorates as the session progresses.

That distinction is important.

If a GPU is operating at 90% utilization during Denoise and completes the operation in approximately 20–24 seconds, that is understandable hardware utilization.

If the same application subsequently becomes increasingly unresponsive while navigating photographs, with GPU utilization low and CPU utilization increasing simply from changing images, the cause may lie elsewhere.

Relevant Current Adobe Community Reports

There are also recent Adobe Community reports that make this behavior particularly worthy of investigation.

A September 2026 Lightroom Classic 15.5.1 report describes progressive memory growth during ordinary Develop navigation. One Windows 10 user reported Lightroom Private Bytes increasing approximately:

6 GB → 9 GB → 15.5 GB → 33.9 GB

The report also describes CPU utilization reaching approximately 78% while Lightroom was being used, with substantial memory remaining allocated after CPU utilization declined. Adobe Community personnel acknowledged the detailed measurements and continued the investigation.

There are also current reports of memory-related and heap-corruption problems associated with Assisted Culling in Lightroom Classic 15.5/15.5.1 on Windows, including reports from systems with substantially more powerful GPUs than mine. Adobe staff have requested additional crash reports and logs for investigation.

I recognize that these reports concern somewhat different Lightroom features and therefore do not prove that my particular problem has the same cause. I mention them because they indicate that resource-management issues in current Lightroom Classic versions are being independently investigated.

Questions for Adobe Engineering

I would appreciate answers to the following:

1. What exactly is stored in the numbered .blob files within .lrcat-data?

2. Why does a brand-new catalog create a .blob of approximately 27 MB?

3. What causes subsequent .blob files to grow to approximately 267 MB each?

4. Does each blob represent a fixed-size storage allocation, a collection of AI information, or another type of Lightroom data?

5. When an image is deleted from a catalog, what happens to the AI-related data associated with that image?

6. Is there an automatic garbage-collection or compaction mechanism for obsolete AI data in .lrcat-data?

7. Can Denoise, Super Resolution, Raw Details, or other AI operations leave data behind after the associated photograph or edit history has been removed?

8. Can the .lrcat-data database be safely compacted without deleting valid AI edits?

9. Is Lightroom Classic 15.5.1 known to retain increasing amounts of memory during extended Develop navigation?

10. Is there an internal memory-management or cache-reclamation threshold that should cause Lightroom to release resources during a long session?

11. Why can Lightroom's CPU utilization rise substantially simply from navigating between photographs when no visible processing operation is occurring?

12. What processing is Lightroom performing during these periods?

13. Could the progressively increasing .lrcat-data and/or AI-data workload contribute to the increased CPU activity and Develop latency?

14. Are there known limitations in Lightroom Classic when dealing with very high-volume culling workflows in which large numbers of photographs are processed and subsequently rejected?

Requested Engineering Investigation

I would encourage Adobe to investigate this as a long-session resource-management problem, rather than simply evaluating whether the user's CPU or GPU is sufficiently powerful.

A useful diagnostic test would be to take a large catalog and monitor, over several hours:

• Lightroom Private Bytes

• Working Set

• Commit Size

• CPU utilization

• GPU utilization

• GPU VRAM allocation

• number and size of .blob files

• .lrcat-data total size

• Develop response latency

• shutdown duration

The measurements should be taken while repeatedly navigating photographs in Develop, performing Denoise, rejecting photographs, deleting photographs, and then allowing Lightroom to sit idle.

The important measurement would be whether Lightroom releases resources and/or reclaims obsolete AI data as the session progresses.

Final Observation

I am not asking Adobe to make Lightroom use less computational power for advanced AI features.

I am asking Adobe to ensure that increasingly sophisticated processing does not result in progressively less efficient management of memory, temporary data, catalog data, and AI-related information.

Users should not necessarily have to purchase increasingly powerful hardware simply to compensate for resource-management inefficiencies in the application.

In my case, the available hardware appears capable of performing the demanding AI operation itself. The concern is what happens after and around that operation as Lightroom continues to be used.

I believe this distinction is important and would appreciate having the issue reviewed by Lightroom Classic engineering.

I am an instructor at Osher Lifelong Learning Institute at Furman University, Greenville, SC where I have been teaching the use of Adobe Lightroom Classic for the past ten years and my students are expressing similar concerns