The Issues(s)

If you manage a serious photo library in Lightroom Classic or similar DAM software, I generally recommend leaving automatic sidecar writing turned off unless you have a specific workflow reason to use it. Advanced hobbyists often have tens or hundreds of thousands of RAW files, multiple drives, previews, smart previews, AI masks, keywords, ratings, and exports in play. At that scale, every extra file matters—not because one XMP file is huge, but because multiplying small files across an entire archive adds file-management overhead, backup churn, and more disk activity. For this article, when I say “disk,” I mean any storage device you may be using: SSD, HDD, NVMe, external USB drive, NAS volume, SAN storage, or memory card-based workflow drive.

This is not really about brand loyalty or whether Lightroom Classic is “better” than another editor. It is about how catalog-based software, operating systems, and storage devices interact when you ask them to track a large image library. Storage is organized around logical sectors, physical sectors, and filesystem allocation blocks. Those details are easy to ignore when you are working on one folder from a weekend shoot, but they become more important when your catalog spans years of RAW files.

Platform OS / Device	Logical Sector Size	Most Common or Default Physical Sector Size	Notes
macOS / (APFS/HFS+)	512B or 4K	4K common	Inherits hardware sector size
Windows / (NTFS/FAT32/exFAT)	512B	4K common	NTFS supports 4K logical but rarely used
Linux / (ext4/XFS/Btrfs)	512B	4K common	Tools show both sizes
Any / USB drives	512B	N/A (flash translation layer)	FAT32/exFAT typical

There are 3 pieces of [file system] information that I need to explain:

• Logical sector size = what the OS reads/writes (commonly 512 bytes or 4K).
• Physical sector size = the actual hardware sector size (commonly 4K on modern HDD/SSD).
• Filesystem block size = the allocation unit used by the filesystem; this varies by filesystem and formatting choices.

When a read request is made, the OS will send commands to the disk to read at least 1 logical sector.  But disk hardware will read the entire physical sector size into its buffer (or cache). It does this in anticipation that you will want the next logical sector and since it is already available the possible next read request can be satisfied quickly.

In Lightroom Classic, XMP sidecars store metadata and many edit instructions outside the catalog, in addition to the data being stored in the Lightroom catalog. Simple metadata-only files may be small, but files can grow as edits, masks, keywords, captions, and other settings accumulate. Recent Lightroom Classic versions can also create an additional ACR sidecar for heavier edits when sidecar storage is enabled, which reinforces the larger point: sidecar workflows add more companion files that must be written, tracked, copied, updated, backed up, and kept beside the original image.

XMP sidecars contain:

• Basic metadata (EXIF, IPTC, rating, flags)
• Develop settings (sliders, masks, profiles)
• Lens corrections
• Camera profiles
• Keywords

They do not contain:

• Previews
• Thumbnails
• History steps
• Smart preview data
• Raw image data

For a working photographer or advanced hobbyist, the practical issue is not that Lightroom cannot read a sidecar. It can. The issue is that you are splitting responsibility across the catalog, the original RAW, preview caches, smart previews, and one or more companion metadata files. That can be useful when you need interoperability with Adobe Camera Raw, Bridge, another culling tool, or a migration workflow. But if Lightroom Classic is your main editing and asset-management environment, the catalog is already designed to be the primary source of truth.

The storage impact is not just raw capacity. It is also file count, filesystem bookkeeping, backup behavior, sync behavior, and the time it takes utilities to scan folders. A few thousand XMP files may not matter. A catalog with 150,000 RAW files, however, can turn “small text files” into a large number of extra filesystem objects. If those folders are being backed up, synchronized, indexed, or moved between drives, every companion file becomes one more item the system must process.

Adobe created XMP, and Lightroom Classic can write standard metadata and develop-related settings to XMP so other Adobe tools and some third-party tools can recognize at least part of your work. That is useful, but it is not the same thing as a universal RAW-editing language. Ratings, keywords, captions, copyright fields, and some adjustment data may travel well between different applications. Lightroom-specific history, collections, smart collections, previews, and some application-specific behavior remain catalog-dependent.

That is the real catch for photographers considering a future move from Lightroom Classic to Capture One, ON1 Photo RAW, DxO PhotoLab, or another editor. XMP can help preserve ratings, keywords, captions, and some edit instructions, but it does not guarantee that another RAW processor will render your images the same way. Each vendor has its own demosaicing engine, tone mapping, color science, masking model, noise reduction, lens correction behavior, and AI features. Your “look” is not just metadata—it is also the processing recipe behind the software.

Let the catalog be The Catalog

Lightroom Classic and similar DAM applications are built around a catalog database. That database tracks image locations, metadata, collections, edits, previews, and relationships between assets. Keeping that information centralized is one of the reasons catalog-based software can filter, search, sort, batch-edit, and display large libraries efficiently. Sidecars can be valuable as an export or interoperability layer, but they are not a replacement for catalog discipline, regular catalog backups, and a reliable image backup strategy.

In the case of Lightroom Classic, there are at least 5 separate files that are in the hundreds of MB or GB in size that contain specific information.

Helper.lrdata: Stores face detection data and AI-related helper indexes

• Face recognition index files
• Facial region maps
• Machine‑learning helper data used by Lightroom’s People view
• Internal caches that speed up face detection and recognition

Previews.lrdata: Stores all Library module previews so Lightroom doesn’t need to render the RAW every time.

• Standard previews (fit-to-screen)
• 1:1 previews (full-resolution)
• Thumbnail previews
• Cached JPEGs generated from your RAW files
• Internal preview metadata

Smart Previews.lrdata: Stores Smart Previews, which are lossy DNG mini‑raws used when originals are offline.

• Compressed DNG files (~1–3 MB each)
• Metadata linking each Smart Preview to its original RAW
• Internal index files

Sync Data.lrdata: Stores cloud sync state for Lightroom Classic ↔ Lightroom (cloud) integration.

• Sync database
• Cloud asset IDs
• Upload/download state
• Flags for synced collections
• Cached metadata for cloud images
• Internal sync logs

Practical recommendation

Component	What It Stores	Why It Exists	Safe to Delete?
Helper.lrdata	Face detection & AI helper data	Speeds up People view	Yes (rebuilds)
Previews.lrdata	JPEG previews (thumb, standard, 1:1)	Fast Library browsing	Yes (rebuilds)
Smart Previews.lrdata	DNG proxy files	Edit offline	Yes (but lose Smart Previews)
Sync Data.lrdata	Cloud sync database	Sync with Lightroom cloud	Yes, but risky (slow rebuild)

My recommendation: if Lightroom Classic is your primary editing and asset-management tool, leave automatic XMP/ACR sidecar writing off and rely on disciplined catalog backups plus full image backups. Use sidecars deliberately when you need them—for example, when moving selected RAW files and edits to Adobe Camera Raw, sharing a small set of images with another Adobe-based workflow, using an external culling tool, or preparing for a controlled migration. In other words, do not make every image carry a sidecar just because the option exists. Make sidecars a tool you use on purpose, not background clutter your entire archive has to manage forever.

Return to the Article index page

0001