What is the SIFT1M dataset?

The SIFT1M dataset is a classic public ANN benchmark of one million 128-dimensional SIFT image descriptors, paired with ten thousand queries and precomputed Euclidean nearest-neighbor ground truth, used to measure recall and speed for indexes such as HNSW.

What exactly is inside SIFT1M?

The release packs four roles that almost every ANN harness expects. The base set holds 1,000,000 float vectors of dimension 128 – the database you index. A separate learn set of 100,000 vectors is available for algorithms that train codebooks or other side models before indexing (HNSW itself usually ignores it). The query set contains 10,000 vectors in the same dimension. Ground-truth files list, for each query, the identifiers of the 100 nearest base vectors ordered by increasing squared Euclidean distance, so recall@k for k up to 100 can be scored without recomputing brute force. Files are commonly distributed in the compact .fvecs / .ivecs binary layouts used across Texmex-style ANN corpora. At float32, the base vectors alone are about 512 MB in memory before any graph edges, which is why SIFT1M became the default "fits on a laptop, still meaningful" scale for graph ANN work.

Those numbers only matter if you also understand what the descriptors represent geometrically.

Where do the vectors come from, and which distance should you use?

SIFT descriptors summarize local image patches – gradient histograms around interest points – not text or multimodal embeddings. Coordinates are real-valued and typically compared with Euclidean (L2) distance; Weaviate’s public tables therefore treat SIFT1M as an l2-squared workload. That choice is not cosmetic: building HNSW with cosine while scoring ground truth with L2 invents a metric-mismatch bug that looks like "bad recall." Relative to modern 768- or 1536-dimensional text embeddings, 128 dimensions are modest, so distance kernels are cheap and cache behavior differs from high-d workloads. Relative to random Gaussian clouds, real SIFT geometry has structure that graph indexes exploit – which is why Weaviate’s debugging tips warn that random vectors often look worse than real corpora at the same size. Treat SIFT1M as an image-descriptor Euclidean problem, not as a stand-in for every production embedding.

That profile is exactly why the dataset became a shared yardstick for HNSW papers and products.

Why do HNSW and Weaviate benchmarks lean on SIFT1M?

One million points is large enough that brute force is painful and approximate search is necessary, yet small enough that full ground truth, repeated parameter sweeps, and peak-RAM experiments stay practical. The public ground truth removes argument about "whose exact k-NN." Weaviate publishes multi-threaded QPS, mean and p99 latency, recall@10 / recall@100, and import time on SIFT1M across HNSW grids of efConstruction, maxConnections, and ef, including a recommended balanced row (for example high-nineties recall@10 at millisecond-scale mean latency under their published machine). Compression and memory write-ups use SIFT1M as the small end of a ladder toward GIST-scale and deeper corpora: float32 base storage is easy to compute by hand (1e6 × 128 × 4 bytes), so graph overhead and quantization savings are easy to explain. When you cite a Weaviate SIFT1M number, carry the operating point and hardware block with it – the dataset name alone is not a full reproducibility manifest.

Knowing when SIFT1M is the wrong proxy is as important as knowing how to load it.

When should you not treat SIFT1M as your production stand-in?

If your live vectors are high-dimensional text or multimodal embeddings under cosine or dot product, SIFT1M’s Euclidean 128-d geometry will not predict your recall-latency knee. If you need billion-scale memory pressure, filtered predicates, or streaming upserts, the million-point static Texmex split will not stress those paths. If you only care about ID-returning microbenchmarks, remember Weaviate’s published SIFT1M timings are end-to-end (network plus object fetch), so matching them with an in-process graph library is an apples-to-oranges comparison. Use SIFT1M to validate that your HNSW implementation and harness are sane, to compare parameter sweeps against a shared curve, and to teach memory math – then move to a corpus whose modality and metric match production.

A short practice checklist keeps SIFT1M experiments comparable.

How should you run an honest SIFT1M HNSW experiment?

Index the base set with squared Euclidean (or L2) consistently with the ground-truth definition. Score recall against the provided neighbors rather than a privately recomputed top-k unless you document why. Sweep ef into a recall-versus-latency or recall-versus-QPS curve; do not publish a single flattering cell. Report hardware, thread count, insertion-order policy, and seeds. If you use Weaviate, say whether latency includes object retrieval. Keep the learn set out of the indexed base unless your method truly needs it for training, and never mix learn vectors into the database without saying so.

SIFT1M is the million-scale Euclidean SIFT yardstick that made HNSW comparisons shareable – small enough to reproduce, large enough to matter. Next, read "What is the GIST1M dataset?" for the higher-dimensional sibling in the same family, then "What is the GloVe embedding dataset?" when you need a text-embedding-shaped contrast to image descriptors.