This article is going to dive deeper into Lightroom Classic and the catalog. If I have the desire to address the Lightroom product then I will try. What we know about the catalog is mostly from what we have read about have seen on various social feeds and educational videos. I will be writing this from the Windows version. The MacOS version is similar in folder and functionality; I just don’t have or want a Mac.
When you create a new LrC catalog the process creates and baseline populates several directories and files. As you continue to use LrC other processes add and delete more files to these directories. For the purposed of the article, I’ve created a new catalog called “[PT]” for Preview Test so when I refer to [PT] and something understand that this is the catalog name.
The LrC Catalog Files/Directories
[PT] Previews.lrdata – Generated preview images (JPEGS) for photos.
- Dynamically changes number of files and subdirectories as you continue to use LrC.
- Lightroom can rebuild it; if deleted, you’ll just lose cached previews until they’re generated again.
[PT] Smart Previews.lrdata – Smart Previews have approximately ~2540 pixels lossy DNG files. Used when the RAW isn’t present.
- Fully editable so you can disconnect from your images and
- If you don’t use Smart Previews, this is not necessary.
[PT] Helper.lrdata – A general support/cache area used by Lightroom Classic for working around/accelerating tasks.
- It’s not the catalog itself; it can be treated as expendable cache in the sense that Lightroom will recreate what’s needed.
[PT] mobile Downloads.lrdata – Stores the originals Lightroom Classic downloaded from the cloud for your mobile device photos (i.e., the “phone downloads” appear as their own device/location in the Folder panel).
- It contains photos, but not your edits (edits are in the catalog) and not the previews (those are in the previews cache).
When LrC is started, 3 files are immediately created.
- [PT].lrcat.lock
- [PT].lrcat-shm
- [PT]-lrcat-wal
The [PT].lrcat.lock (catalog lock file)
- Used to indicate the catalog is currently open by Lightroom Classic (or that another instance attempted to open it).
- Prevents opening the same catalog in a way that would corrupt it (especially if Lightroom crashes mid-session, the .lock can sometimes remain until cleared).
[PT].lrcat-shm (shared memory file)
- A small file used by Lightroom/SQLite to coordinate access to the catalog while it’s open.
- Helps with concurrency/performance for the database engine (not your photo originals; not your edits “separately”).
[PT].lrcat-wal (Write-Ahead Log file)
- Part of the SQLite “WAL” mechanism.
- Temporarily stores recent catalog changes so they’re durable and reduce write overhead.
- When Lightroom closes cleanly, WAL data is typically checkpointed/merged back into the [PT].lrcat as part of normal operation.
These 3 files are temporary (.lock, .shm, and .wal) files that LrC creates are dynamic files and normally get deleted when LrC closes.
Lightroom uses SQLite as its database or catalog. This database platform is Open Source and released under the Public Domain, so it is free with no copyright. Adobe doesn’t have to pay a licensing fee if there is an acknowledgement that the software is being used. You can find the acknowledgement under the Help | About in the main menu) and it’s just 1 line.
SQLite is a relational database which means that standard SQL (Structured Query Language) can be used in Lightroom. The way that programs like LrC access data is through an API (Application Program Interface). Simply, a request is made by the program to the database to send or receive certain data from the database. The Database engine (SQLite) gets the request, gathers the data and provides it to the requesting program. This is the industry standard on how programs work, they do it through the API.
One of the primary features of LrC is the non-destructive editing and often we are reminded that the original image is never touched. When doing anything to the image it is recorded to the database and we see the result of that change and is stored in the Catalog (SQLite database) and the image that we are viewing is regenerated and stored in the [PR]Previews.lrdata directory. The specific directory and filename of this preview is updated in the Catalog (SQLite database). When we want to look at an image, a SQL request is made to get the directory and file name of the preview, and it is displayed and the associated history of changes made to the image and any snapshots are also obtained.
Disk Activity In The LrC Catalog
The purpose of this is to explain the large amount of file activity that is ongoing in LrC. The preview files and the SQLite database are constantly being updated. We expect updated results fast and immediately. The truth is that LrC can only operate as fast as your computer system (mostly disk I/O) will allow and everything is a tradeoff. A Catalog (SQLite Database) stored on a traditional spinning disk (HDD) is limited to the data transfer rate and ability of the drive to read/write information to the file. Solid State (SSD, NvME) drives are faster read/write but are higher in cost and limited in size. The configuration of the computer and the LrC application itself can also affect how fast we see results.
Think long and hard before ever putting the Lr catalog on a USB connected, external disk drive. For example, it may work acceptably for a very small catalog used on a laptop while you are on vacation to store & edit your vacation photos. While a USB connected external disk device (HDD or SSD) is relatively fast, they are not nearly as fast as an internal HDD or SSD inside your computer.
Just like there is no “Make my image beautiful” button that fixes everything, there is no “make LrC run better/faster” configuration option.
In the next articles I will try to demonstrate the activity LrC is taking.
Return to the Article index page
0004
Recent Posts
Recent Comments
No comments to show.