It started with a simple question

Rather than relying on specifications or theoretical limits, there was an opportunity to test that assumption using three real Photo Supreme catalogs:

• approximately 20,000 images

• approximately 160,000 images

• approximately 700,000 images

  
  

A catalog containing 700,000 photographs sounds intimidating. But does a 700K catalog actually make every operation dramatically slower than a 20K catalog?

That turned out to be the more interesting question.

These are not scientific benchmarks. The catalogs contain different subject matter and metadata distributions, and timings are approximate user-facing observations. But they are real catalogs rather than synthetic databases constructed specifically for benchmarking. This article is published by the maker of Photo Supreme, so it should be read as a transparent real-world product note rather than independent third-party testing.

A little terminology

For readers unfamiliar with Photo Supreme, a few terms may help.

Photo Supreme is Digital Asset Management software for photographers. The Collection Viewer is its main thumbnail area.

Catalog Labels provide a hierarchical way to classify photographs independently of their physical folders. For example: Animals > Birds > Raptors > Eagles. A recursive selection can retrieve images belonging to a label and its subordinate hierarchy.

The global Search Box searches broadly across indexed catalog information. It is not simply a filename search; searchable information can include metadata, filenames, Catalog Labels, descriptions and other catalog content.

These distinctions matter because the different operations exercise a DAM in different ways.

The test machine

All tests were performed on the same Windows PC.

Processor; AMD Ryzen 7 8745H

Graphics; AMD Radeon 780M integrated graphics

RAM; 32 GB DDR5-5600

SSD; Crucial T500 1TB PCIe 4.0 NVMe

Operating system; Windows 11 Pro 25H2

Photo Supreme; 2026.3.2.9499

Edition / database; Single User / SQLite

The machine is best characterized as a modern mid-range PC with a particularly strong SSD, rather than a high-end workstation.

Storage is relevant here. The catalogs were on the internal Crucial T500 NVMe SSD, and the Photo Supreme catalog folder was excluded from Windows Defender's real-time scanning. Local SQLite performance can be affected by storage latency and, on some systems, antivirus inspection of active database files.

The SSD was approximately 86% full at the time, so this was not a pristine empty benchmark drive.

First test: open everything

The first test was deliberately simple: Open a very large collection.

These were cold, first-run observations after startup.

20K catalog; opens ~20,000 images in ~0.5 s

160K catalog; opens ~160,000 images in ~5.5 s

700K catalog; opens 697,213/250,000 cap in ~6 s

The 700K case behaved differently. At that size, Photo Supreme does not offer the normal "All" selection, so a high-level catalog node containing 697,213 images was selected instead. Photo Supreme limits the returned Collection Viewer result to the first 250,000 images.

This is intentional. There is an important difference between the number of assets a DAM can catalog and the number that are useful to place into one active thumbnail view.

Normally, searches, categories and filters are used to turn a huge archive into a useful working collection. That distinction between catalog size and active collection size became important throughout the experiment.

Opening is only half the story

Once the collections appeared, something more interesting happened: Scrolling remained smooth in all three catalogs.

When a thumbnail is not yet available, Photo Supreme temporarily displays a colored stub. The actual thumbnail replaces it as it becomes available, without forcing scrolling to wait.

Large collections are handled progressively rather than requiring the complete result to be fully prepared before useful interaction can begin.

The result is an important distinction:

> The amount of work still taking place and the responsiveness experienced by the user are not necessarily the same thing.

The architectural thinking behind this is discussed separately in the Behind the Design article Designing for Responsiveness. Here, the interesting part is simply how that behaviour holds up as catalog size increases.

Searching hundreds of thousands of images

The next tests used Photo Supreme's global Search Box.

Initial results were:

20K catalog; finds 5,240 images in <1 s

160K catalog; finds 142,637 images in ~7 s

700K catalog; finds 66,429 in ~4 s

Curiously, the 700K catalog completed faster than the 160K catalog.

The obvious difference was the number of returned results: approximately 143K versus 66K.

A three-term A AND B AND C search produced another unexpected comparison:

20K catalog; finds 133 images in < 0.5 s

160K catalog; finds 254 images in ~5 s

700K catalog; finds 534 images in ~3 s

Again, the largest catalog wasn't the slowest.

Two searches producing similar final result counts do not necessarily represent equivalent workloads. Global Search operates across different indexed search domains, and the amount of work can vary depending on what matches and how those matches relate back to the catalog.

So there is no useful rule saying:

> Twice as many cataloged images should mean twice as long to search.

A more comparable search

Finding equivalent searches across three unrelated catalogs proved surprisingly difficult. Eventually, the following reasonably comparable results were obtained:

20K catalog; finds 16,540 images in ~1 s

160K catalog; finds 35,725 images in ~2 s

700K catalog; finds 32,965 images in ~5 s

The 160K and 700K results are the most useful comparison.

The catalog became approximately 4.4× larger, while searches returning roughly 33K–36K results went from approximately 2 to 5 seconds.

These observations are too informal to derive a mathematical scaling law. They do show, however, that global search becomes more noticeable as the catalog grows without simply increasing in direct proportion to catalog size.

Catalog Labels told a different story

Catalog Label retrieval produced much more consistent results.

20K catalog; finds Label X with 2,440 images in <0.5 s

20K catalog; finds Label Y with 1,773 images in <0.5 s

160K catalog; finds Label X with 2,142 images in <0.5 s

160K catalog; finds Label Y with 1,633 images in <0.5 s

700K catalog; finds Label X with 2,713 images in <0.5 s

700K catalog; finds Label X with 1,666 images in <0.5 s

All felt essentially instantaneous.

The same test using recursive Catalog Labels returned substantially larger collections:

20K catalog; finds 11,393 images recursively in <0.5 s

160K catalog; finds 12,487 images recursively in <0.5 s

700K catalog; finds 10,722 images recursively in <0.5 s

Across a 35× increase in catalog size, retrieval of roughly 11K–12K assets through the catalog hierarchy remained below the approximate half-second measurement threshold. Optimized database indexing plays an important role here, but the broader lesson is more useful:

> “How fast is a 700K catalog?” is not really a complete question.

Searching globally, retrieving a Catalog Label and displaying hundreds of thousands of assets are very different workloads.

What about memory?

Windows Task Manager produced the following measurements:

Idle after startup = 149 MB

After loading 20K images = 301 MB

After loading 160K images = 721 MB

After loading 250K images = 1,082 MB

The practical result is straightforward:

> Even with 250,000 images in the active collection, Photo Supreme used approximately 1.1 GB of process memory.

Memory growth remained predictable rather than exploding as the collection became larger.

Thumbnail memory is also separate from the memory needed to represent the active collection. Photo Supreme maintains thumbnail data as a limited working cache rather than retaining decoded thumbnails for hundreds of thousands of images.

This helps explain why extremely large collections can remain practical without requiring extraordinary amounts of RAM.

SQLite wasn't the bottleneck

All tests, including the 700K catalog, used the Single User edition with SQLite.

Nothing in these tests indicated that catalog size itself required moving away from SQLite. Photo Supreme's PostgreSQL and SQL Server options primarily address concurrent use, rather than being an obligatory upgrade path simply because a catalog becomes large.

Storage does matter. SQLite operates against a local database, making disk latency and throughput relevant.

Real-time antivirus scanning can matter too. On some systems, scanning SQLite's supporting database activity can noticeably affect performance. When investigating unexpectedly poor database performance, excluding the Photo Supreme catalog folder from real-time antivirus scanning is therefore worth considering.

So, is 500K a large Photo Supreme catalog?

That was the question that started the experiment.

On the tested machine:

> 160K was comfortably practical.

The complete collection opened in several seconds. Catalog Label navigation and recursive retrieval remained effectively instantaneous. Scrolling remained smooth. Memory consumption remained modest.

> The 700K catalog provided a much more demanding test.

Broad global searches became more noticeable, particularly when returning tens of thousands of results. Extremely large active collections naturally required more preparation time and memory.

But basic interaction remained responsive.

The experiment therefore points toward a more useful conclusion:

> Catalog size alone is a surprisingly poor predictor of how a DAM will feel to use.

The operation matters. The query matters. The number of returned assets matters. Storage matters. And the way work is integrated into the user experience matters.

What the experiment revealed

This was never intended to become a formal benchmark. It began with a simple question and evolved because each result suggested another test.

Putting the 20K, 160K and 700K results side by side made several things particularly clear:

• catalog size and active collection size are different concerns

• global search and Catalog Label retrieval have different performance characteristics

• very large result sets can matter more than very large underlying catalogs

• memory remains manageable even with extremely large active collections

• smooth interaction does not require all background work to have completed

• edge-case benchmarks can reveal genuine trade-offs without representing normal use

For a Photo Supreme catalog expected to grow to 500K images, these observations provide little reason to regard that growth as problematic on comparable hardware. Curiosity eventually pushed the experiment all the way to 700K images, where the differences between operations became much more visible; but the catalog remained comfortably usable in the workflows tested.