Vector Search for Event Photo Matching, Explained
TIME&SPACE · Event Technology
Vector search is how a selfie finds the right event photos in under a second. Here is what happens between the scan and the gallery.
A guest scans a QR code, takes one selfie, and sees only the photos they appear in. It feels instant and a little magical. Behind that moment sits a specific piece of technology doing the heavy lifting: vector search. It is the reason a single face can be compared against tens of thousands of photos in well under a second, without anyone tagging a name to a single image.
Vector search is a method of finding the closest items in a dataset by comparing numerical representations of their meaning rather than matching exact text or keywords. For event photos, it turns every face into a list of numbers and then finds the faces that sit nearest to a guest's selfie. This guide explains how that pipeline works at an event, why it is fast, and what makes it accurate enough to trust.
From a Face to a Vector
The first step has nothing to do with searching. It is about turning a face into something a computer can compare.
When a photo is uploaded, a face recognition model scans it, locates every face, and converts each one into an embedding. An embedding is a fixed-length list of numbers, often 512 of them, that encodes the geometry of a face: the spacing of the eyes, the shape of the jaw, the relationship between dozens of facial landmarks. Two photos of the same person produce two embeddings that sit very close together in that 512-dimensional space. Two different people produce embeddings that sit far apart.
TIME&SPACE uses an ArcFace-based model from the open-source InsightFace project to generate these 512-number embeddings. The same model runs on the guest selfie at scan time, so the selfie and the photos are described in exactly the same language. This is the crucial detail. You cannot compare a face to a face directly, but you can compare two lists of numbers very efficiently.
Why It Is Called a Vector
A list of 512 numbers is, mathematically, a vector: a single point in a space with 512 dimensions. Humans cannot picture 512 dimensions, but the logic is the same as it is in two. On a flat map, two towns are close if their coordinates are similar. In a face embedding space, two faces are close if their 512 coordinates are similar.
That closeness is what the system measures. The most common measure for face embeddings is cosine similarity, which compares the angle between two vectors rather than the raw distance between them. When two embeddings point in almost the same direction, the cosine similarity is near one, and the system treats them as the same person. When they point in different directions, the score drops, and the system treats them as different people. Matching faces becomes a geometry problem, and geometry is something a database can solve at scale.
Searching Without Checking Every Photo
Here is where the speed comes from. A large festival might generate 40,000 photos and 120,000 individual faces. Comparing a guest selfie to every one of those faces, one by one, would work, but it would be slow and would not scale.
Vector databases avoid the brute-force approach using an index built for nearest-neighbour search. Instead of scanning every face, the index groups similar embeddings together in advance, so a query only has to look in the neighbourhoods that matter. TIME&SPACE stores its embeddings in PostgreSQL using the pgvector extension, which adds a native vector column type and approximate nearest-neighbour indexing directly to the database. The selfie vector goes in, the index narrows the search to the most promising candidates, and the closest matches come back in milliseconds.
The trade-off is in the word "approximate". An exact search checks everything and is perfectly thorough but slow. An approximate search is dramatically faster and, tuned correctly, returns the same matches a guest would care about. For event photo delivery, where the goal is to surface a person's photos in real time at a live venue, that trade is well worth making. Recent releases of pgvector, including the 0.8.0 update, have improved both the speed and the quality of this indexing, which is why a database-native approach now holds up at festival scale.
The Threshold Decides What Counts as a Match
Finding the nearest faces is only half the job. The system still has to decide which of those near faces are actually the same person and which are merely similar-looking strangers. That decision comes down to a single tuned number: the threshold.
The threshold is the minimum similarity score a candidate must clear to be shown to the guest. Set it too loose and the gallery fills with near-misses: people who share a hairstyle or a jaw shape. Set it too tight and the system rejects genuine photos where the guest is turned slightly away from the camera or lit differently than in their selfie. The right threshold sits at the point where almost every real photo gets through and almost no stranger does. This is the same balance we cover in detail in our guide to how facial recognition accuracy works.
Lighting, angle, motion blur, and partial faces all push a real match's score downward, which is why event conditions are harder than a passport photo. A well-tuned vector search system accounts for this by combining a sensible threshold with a re-match pass that catches faces the first scan missed.
Why Vector Search Beats Tagging and Folders
The older ways of delivering event photos all put work on a human. Someone has to tag names, sort images into folders, or ask guests to scroll through thousands of pictures hoping to spot themselves. Vector search removes that work entirely. No one labels a single face. The guest's own selfie is the only input the system needs, and it produces a personal gallery automatically.
That is also what makes it private by design. The system never needs a guest's name, email, or social profile to find their photos. It only needs a momentary selfie, which is converted to a vector, used for the match, and then handled under strict retention rules. For a deeper look at the guest-facing side of this, see how face recognition finds your event photos. If you are planning delivery for your own event, our organiser guide walks through the full setup, and the pricing page covers the per-event plans.
What This Means for Your Event
For an organiser, the technology should be invisible. What matters is the outcome: guests find their photos in seconds, the gallery feels personal, and nobody spends a night tagging images. Vector search is the engine that makes that outcome possible at any scale, from a 200-person corporate dinner to a 15,000-person festival.
The numbers behind it are abstract, but the experience is not. A guest takes one selfie and walks away with every photo of themselves. That is the whole point, and vector search is how it happens.
Frequently Asked Questions
What is vector search in simple terms? Vector search is a way of finding the most similar items in a large collection by comparing numerical fingerprints of their content. For event photos, each face becomes a list of numbers, and the system finds the faces whose numbers are closest to a guest's selfie.
How fast is vector search for event photos? A tuned vector search returns matches in milliseconds, even across tens of thousands of photos. The speed comes from an index that narrows the search to likely candidates instead of comparing every face one by one.
Is vector search accurate enough for large events? Yes, when it is paired with a good face model and a correctly tuned similarity threshold. The threshold sets how strict a match must be, balancing the risk of showing strangers against the risk of missing genuine photos.
Does vector search store my face permanently? No. The selfie embedding is used for the match and then handled under strict retention rules. The system needs no name, email, or account to find a guest's photos, which keeps the process private by design.
What technology does TIME&SPACE use for vector search? TIME&SPACE generates 512-dimension face embeddings with an ArcFace model and stores them in PostgreSQL using the pgvector extension, which provides native vector storage and nearest-neighbour indexing inside the database.
Founder, TIME&SPACE