If you've used Photo Supreme for a while, you've probably noticed that searching feels different. There is a single search box. You don't need to tell it whether you're searching filenames, descriptions, catalog labels, annotations, or other metadata. You simply type what you remember, and Photo Supreme searches where it makes sense. That behavior is not an accident. It is the result of a conscious design decision that dates back to the early design of Photo Supreme.

The problem

A Digital Asset Management (DAM) system is fundamentally different from a document database. When searching documents, users often know what they are looking for. They search the contents of a document or a title. Photographers usually remember fragments.

Perhaps they remember:

• a species name

• part of a filename

• a location

• a lens

• a word from a caption

• an observation number

• a person

• a rating

They usually don't remember where that information is stored. A search engine for a DAM therefore has a different goal:

The first design goal

One of the earliest requirements for Photo Supreme was therefore simple:

That immediately ruled out many traditional search approaches that expect users to choose a field before searching. Instead, Photo Supreme builds its own search index during cataloging.

Why not use database Full-Text Search?

This is a question that occasionally comes up. Modern databases such as SQLite, SQLServer and PostgreSQL all provide Full-Text Search (FTS) capabilities. They are excellent technologies and well suited for many applications.

However, Photo Supreme has requirements that go beyond generic text search. One of the most important requirements is consistency. Photo Supreme supports multiple database engines. Whether a catalog is stored in SQLite, SQLServer or PostgreSQL, users should receive identical search results.

Native Full-Text Search implementations differ in several ways:

• tokenization

• language handling

• stemming

• stop words

• ranking

• matching behavior

Those differences are perfectly reasonable because each database engine has different goals.

For Photo Supreme, however, the search experience should not depend on the database backend.

Search should be a feature of Photo Supreme: not a feature of the database.

Tokenization instead of text indexing

Rather than indexing raw metadata text directly, Photo Supreme first converts textual metadata into searchable tokens. These tokens are stored in a dedicated search index.

This has several advantages. Searches no longer operate on raw metadata fields. Instead they operate on an optimized search structure built specifically for Photo Supreme. Because token generation is controlled by Photo Supreme itself, search behavior remains identical across all supported database engines.

More than words

An advantage of controlling token generation is that Photo Supreme is not limited by how a database defines a "word". For example, a metadata value or file name containing the word:

bookshelf

may generate searchable tokens such as:

bookshelf
book
shelf

Likewise, a filename or description containing:

White-tailed Eagle

can generate tokens that make searching intuitive without requiring users to remember the exact original text. This flexibility allows Photo Supreme to optimize search behavior for photographic metadata instead of generic document search.

Building the index

Creating the search index happens transparently while cataloging images. To efficiently resolve tokens against an ever-growing vocabulary, Photo Supreme maintains an indexed internal dictionary with a BK-tree. This enables sophisticated token resolution without compromising performance, keeping both indexing and searches exceptionally fast, even for catalogs containing millions of metadata values.

The additional work is performed once during cataloging. The benefit is that searches themselves become extremely lightweight because they operate on precomputed relationships between tokens and catalog objects.

Trade-offs

Every engineering decision has trade-offs. Building a dedicated search index means:

• more work during cataloging

• additional storage for the search index

• more complexity inside Photo Supreme

  
  

In return, Photo Supreme gains:

• identical search behavior across all supported database engines

• complete control over token generation

• domain-specific search behavior

• fast global searches

• the freedom to evolve search capabilities independently of the underlying database technology

  
  

A design philosophy

The goal of Photo Supreme has never been to expose database technology to the user. The goal has always been much simpler. When searching, users should type whatever they remember. Photo Supreme should determine where that information lives. That philosophy has guided the search architecture from the beginning and continues to shape its evolution today.

In the next Behind the Design

This article focused on search.

In future articles we'll explore other design decisions behind Photo Supreme, including:

• Why metadata comes before folders.

• How Dynamic Collections work conceptually.

• Why Stacks and Version Sets exist.

• Designing a catalog that scales from thousands to millions of images.

• Why consistency often wins over convenience.