TigerData logo
TigerData logo
  • Product

    Tiger Cloud

    Robust elastic cloud platform for startups and enterprises

    Agentic Postgres

    Postgres for Agents

    TimescaleDB

    Postgres for time-series, real-time analytics and events

  • Docs
  • Pricing

    Pricing

    Enterprise Tier

  • Developer Hub

    Changelog

    Benchmarks

    Blog

    Community

    Customer Stories

    Events

    Support

    Integrations

    Launch Hub

  • Company

    Contact us

    About

    Timescale

    Partners

    Security

    Careers

Log InTry for free
Home
What Are Open-Source Time-Series Databases—Understanding Your OptionsWhy Consider Using PostgreSQL for Time-Series Data?Alternatives to TimescaleTime-Series Analysis in RAWS Time-Series Database: Understanding Your OptionsWhat Is Temporal Data?What Is a Time Series and How Is It Used?Is Your Data Time Series? Data Types Supported by PostgreSQL and TimescaleUnderstanding Database Workloads: Variable, Bursty, and Uniform PatternsHow to Work With Time Series in Python?Tools for Working With Time-Series Analysis in PythonGuide to Time-Series Analysis in PythonTime-Series Analysis and Forecasting With Python The Best Time-Series Databases ComparedUnderstanding Autoregressive Time-Series ModelingStationary Time-Series AnalysisCreating a Fast Time-Series Graph With Postgres Materialized Views
Using PostgreSQL UPDATE With JOINUnderstanding PostgreSQLHow to Install PostgreSQL on MacOSWhat Is Data Compression and How Does It Work?What Is Data Transformation, and Why Is It Important?Optimizing Your Database: A Deep Dive into PostgreSQL Data TypesHow to Install PostgreSQL on LinuxHow to Address ‘Error: Could Not Resize Shared Memory Segment’ 5 Common Connection Errors in PostgreSQL and How to Solve ThemUnderstanding HAVING in PostgreSQL (With Examples)How to Fix No Partition of Relation Found for Row in Postgres DatabasesUnderstanding GROUP BY in PostgreSQL (With Examples)How to Fix Transaction ID Wraparound ExhaustionUnderstanding PostgreSQL Date and Time FunctionsUnderstanding ACID Compliance Understanding percentile_cont() and percentile_disc() in PostgreSQLUnderstanding PostgreSQL Conditional FunctionsUnderstanding PostgreSQL Array FunctionsWhat Characters Are Allowed in PostgreSQL Strings?Understanding FROM in PostgreSQL (With Examples)Understanding FILTER in PostgreSQL (With Examples)Understanding LIMIT in PostgreSQL (With Examples)Understanding ORDER BY in PostgreSQL (With Examples)Understanding WINDOW in PostgreSQL (With Examples)Understanding PostgreSQL WITHIN GROUPPostgreSQL Mathematical Functions: Enhancing Coding EfficiencyUnderstanding DISTINCT in PostgreSQL (With Examples)Using PostgreSQL String Functions for Improved Data AnalysisData Processing With PostgreSQL Window FunctionsUnderstanding WHERE in PostgreSQL (With Examples)PostgreSQL Joins : A SummaryWhat Is a PostgreSQL Left Join? And a Right Join?PostgreSQL Join Type TheoryData Partitioning: What It Is and Why It MattersUnderstanding PostgreSQL's COALESCE FunctionUnderstanding PostgreSQL FunctionsUnderstanding OFFSET in PostgreSQL (With Examples)Understanding the Postgres string_agg FunctionSelf-Hosted or Cloud Database? A Countryside Reflection on Infrastructure ChoicesUnderstanding PostgreSQL User-Defined FunctionsStructured vs. Semi-Structured vs. Unstructured Data in PostgreSQLUnderstanding SQL Aggregate FunctionsUnderstanding Foreign Keys in PostgreSQLWhat Is a PostgreSQL Full Outer Join?What Is a PostgreSQL Cross Join?What Is a PostgreSQL Inner Join?Understanding PostgreSQL SELECTA Guide to PostgreSQL ViewsStrategies for Improving Postgres JOIN PerformanceUnderstanding the Postgres extract() FunctionUnderstanding the rank() and dense_rank() Functions in PostgreSQL
What Is Audit Logging and How to Enable It in PostgreSQLWhen to Consider Postgres PartitioningTop PostgreSQL Drivers for PythonPostgreSQL Performance Tuning: Optimizing Database IndexesDetermining the Optimal Postgres Partition SizeBest Practices for (Time-)Series Metadata Tables Guide to Postgres Data ManagementHow to Query JSONB in PostgreSQLHow to Index JSONB Columns in PostgreSQLHow to Monitor and Optimize PostgreSQL Index PerformanceOptimizing Array Queries With GIN Indexes in PostgreSQLSQL/JSON Data Model and JSON in SQL: A PostgreSQL PerspectiveHow to Query JSON Metadata in PostgreSQLA Guide to pg_restore (and pg_restore Example)Handling Large Objects in PostgresPostgreSQL Performance Tuning: Designing and Implementing Your Database SchemaPostgreSQL Performance Tuning: Key ParametersHow to Reduce Bloat in Large PostgreSQL TablesGuide to PostgreSQL Database OperationsPostgreSQL Performance Tuning: How to Size Your DatabaseGuide to PostgreSQL PerformanceNavigating Growing PostgreSQL Tables With Partitioning (and More)An Intro to Data Modeling on PostgreSQLDesigning Your Database Schema: Wide vs. Narrow Postgres TablesExplaining PostgreSQL EXPLAINBest Practices for Time-Series Data Modeling: Single or Multiple Partitioned Table(s) a.k.a. Hypertables What Is a PostgreSQL Temporary View?A PostgreSQL Database Replication GuideUnderstanding PostgreSQL TablespacesA Guide to Data Analysis on PostgreSQLHow to Compute Standard Deviation With PostgreSQLBuilding a Scalable DatabaseA Guide to Scaling PostgreSQLPg_partman vs. Hypertables for Postgres PartitioningHow to Use PostgreSQL for Data TransformationRecursive Query in SQL: What It Is, and How to Write OneHow PostgreSQL Data Aggregation WorksGuide to PostgreSQL Database DesignGuide to PostgreSQL SecurityHow to Use Psycopg2: The PostgreSQL Adapter for Python
How to Manage Your Data With Data Retention PoliciesBest Practices for Scaling PostgreSQLBest Practices for PostgreSQL Database OperationsHow to Store Video in PostgreSQL Using BYTEAHow to Handle High-Cardinality Data in PostgreSQLHow to Use PostgreSQL for Data NormalizationTesting Postgres Ingest: INSERT vs. Batch INSERT vs. COPYBest Practices for Postgres SecurityBest Practices for Postgres Data ManagementBest Practices for Postgres PerformanceHow to Design Your PostgreSQL Database: Two Schema ExamplesBest Practices for PostgreSQL Data AnalysisBest Practices for PostgreSQL AggregationBest Practices for Postgres Database ReplicationHow to Use a Common Table Expression (CTE) in SQL
PostgreSQL Extensions: Unlocking Multidimensional Points With Cube PostgreSQL Extensions: hstorePostgreSQL Extensions: ltreePostgreSQL Extensions: pg_prewarmPostgreSQL Extensions: pgRoutingPostgreSQL Extensions: Using PostGIS and Timescale for Advanced Geospatial InsightsPostgreSQL Extensions: Turning PostgreSQL Into a Vector Database With pgvectorPostgreSQL Extensions: amcheckPostgreSQL Extensions: Secure Your Time-Series Data With pgcryptoPostgreSQL Extensions: pg_stat_statementsPostgreSQL Extensions: Database Testing With pgTAPPostgreSQL Extensions: Install pg_trgm for Data MatchingPostgreSQL Extensions: PL/pgSQLPostgreSQL Extensions: Intro to uuid-ossp
What Is the Best Database for Real-Time AnalyticsPostgreSQL as a Real-Time Analytics DatabaseUnderstanding OLTPHow to Build an IoT Pipeline for Real-Time Analytics in PostgreSQLHow to Choose a Real-Time Analytics DatabaseOLAP Workloads on PostgreSQL: A GuideHow to Choose an OLAP DatabaseData Analytics vs. Real-Time Analytics: How to Pick Your Database (and Why It Should Be PostgreSQL)Columnar Databases vs. Row-Oriented Databases: Which to Choose?
A Brief History of AI: How Did We Get Here, and What's Next?A Beginner’s Guide to Vector EmbeddingsPostgreSQL as a Vector Database: A Pgvector TutorialUsing Pgvector With PythonHow to Choose a Vector DatabaseVector Databases Are the Wrong AbstractionUnderstanding DiskANNStreaming DiskANN: How We Made PostgreSQL as Fast as Pinecone for Vector DataA Guide to Cosine SimilarityImplementing Cosine Similarity in PythonVector Database Basics: HNSWVector Database Options for AWSVector Store vs. Vector Database: Understanding the ConnectionHow to Build LLM Applications With Pgvector Vector Store in LangChainHow to Implement RAG With Amazon Bedrock and LangChainRetrieval-Augmented Generation With Claude Sonnet 3.5 and PgvectorRAG Is More Than Just Vector SearchPostgreSQL Hybrid Search Using Pgvector and CohereImplementing Filtered Semantic Search Using Pgvector and JavaScriptRefining Vector Search Queries With Time Filters in Pgvector: A TutorialVector Search vs Semantic SearchText-to-SQL: A Developer’s Zero-to-Hero GuidePgvector vs. Pinecone: Vector Database Performance and Cost ComparisonWhat Is Vector Search? Nearest Neighbor Indexes: What Are IVFFlat Indexes in Pgvector and How Do They WorkUnderstanding Semantic SearchBuilding an AI Image Gallery With OpenAI CLIP, Claude Sonnet 3.5, and PgvectorWhen Should You Use Full-Text Search vs. Vector Search?HNSW vs. DiskANN
Understanding IoT (Internet of Things)Storing IoT Data: 8 Reasons Why You Should Use PostgreSQLHow to Choose an IoT DatabaseHow to Simulate a Basic IoT Sensor Dataset on PostgreSQLFrom Ingest to Insights in Milliseconds: Everactive's Tech Transformation With TimescaleHow Ndustrial Is Providing Fast Real-Time Queries and Safely Storing Client Data With 97 % CompressionA Beginner’s Guide to IIoT and Industry 4.0Why You Should Use PostgreSQL for Industrial IoT DataHow Hopthru Powers Real-Time Transit Analytics From a 1 TB Table Migrating a Low-Code IoT Platform Storing 20M Records/DayMoving Past Legacy Systems: Data Historian vs. Time-Series DatabaseHow United Manufacturing Hub Is Introducing Open Source to ManufacturingBuilding IoT Pipelines for Faster Analytics With IoT CoreVisualizing IoT Data at Scale With Hopara and TimescaleDB
What Is ClickHouse and How Does It Compare to PostgreSQL and TimescaleDB for Time Series?Timescale vs. Amazon RDS PostgreSQL: Up to 350x Faster Queries, 44 % Faster Ingest, 95 % Storage Savings for Time-Series DataWhat We Learned From Benchmarking Amazon Aurora PostgreSQL ServerlessTimescaleDB vs. Amazon Timestream: 6,000x Higher Inserts, 5-175x Faster Queries, 150-220x CheaperHow to Store Time-Series Data in MongoDB and Why That’s a Bad IdeaPostgreSQL + TimescaleDB: 1,000x Faster Queries, 90 % Data Compression, and Much MoreEye or the Tiger: Benchmarking Cassandra vs. TimescaleDB for Time-Series Data
Alternatives to RDSWhy Is RDS so Expensive? Understanding RDS Pricing and CostsEstimating RDS CostsHow to Migrate From AWS RDS for PostgreSQL to TimescaleAmazon Aurora vs. RDS: Understanding the Difference
What InfluxDB Got Wrong5 InfluxDB Alternatives for Your Time-Series Data8 Reasons to Choose Timescale as Your InfluxDB Alternative InfluxQL, Flux, and SQL: Which Query Language Is Best? (With Cheatsheet)TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data
How to Migrate Your Data to Timescale (3 Ways)Postgres TOAST vs. Timescale CompressionBuilding Python Apps With PostgreSQL: A Developer's GuideMore Time-Series Data Analysis, Fewer Lines of Code: Meet HyperfunctionsTimescale Tips: Testing Your Chunk SizeIs Postgres Partitioning Really That Hard? An Introduction To HypertablesPostgreSQL Materialized Views and Where to Find Them5 Ways to Monitor Your PostgreSQL DatabaseData Visualization in PostgreSQL With Apache Superset
Postgres cheat sheet
HomeTime series basicsPostgres basicsPostgres guidesPostgres best practicesPostgres extensionsPostgres for real-time analytics
Sections

AI and vector fundamentals

A Brief History of AI: How Did We Get Here, and What's Next?A Beginner’s Guide to Vector EmbeddingsPostgreSQL as a Vector Database: A Pgvector TutorialUsing Pgvector With PythonHow to Choose a Vector DatabaseVector Databases Are the Wrong Abstraction

Cosine similarity

A Guide to Cosine SimilarityImplementing Cosine Similarity in Python

Vector databases

Vector Database Options for AWSVector Store vs. Vector Database: Understanding the Connection

Vectorscale

Fundamentals

Understanding DiskANNHNSW vs. DiskANN

Schema design

Streaming DiskANN: How We Made PostgreSQL as Fast as Pinecone for Vector Data
Vector Database Basics: HNSW

Benchmarks

Pgvector vs. Pinecone: Vector Database Performance and Cost Comparison
Nearest Neighbor Indexes: What Are IVFFlat Indexes in Pgvector and How Do They Work

Tutorials

How to Build LLM Applications With Pgvector Vector Store in LangChainHow to Implement RAG With Amazon Bedrock and LangChainRetrieval-Augmented Generation With Claude Sonnet 3.5 and PgvectorRAG Is More Than Just Vector Search

Hybrid search & filtering

PostgreSQL Hybrid Search Using Pgvector and CohereImplementing Filtered Semantic Search Using Pgvector and JavaScriptRefining Vector Search Queries With Time Filters in Pgvector: A Tutorial

Semantic search

Fundamentals

Understanding Semantic SearchWhat Is Vector Search? Vector Search vs Semantic SearchWhen Should You Use Full-Text Search vs. Vector Search?

Image search

Building an AI Image Gallery With OpenAI CLIP, Claude Sonnet 3.5, and Pgvector

AI query interfaces

Text-to-SQL: A Developer’s Zero-to-Hero Guide

Products

Time Series and Analytics AI and Vector Enterprise Plan Cloud Status Support Security Cloud Terms of Service

Learn

Documentation Blog Forum Tutorials Changelog Success Stories Time Series Database

Company

Contact Us Careers About Brand Community Code Of Conduct Events

Subscribe to the Tiger Data Newsletter

By submitting, you acknowledge Tiger Data's Privacy Policy

2025 (c) Timescale, Inc., d/b/a Tiger Data. All rights reserved.

Privacy preferences
LegalPrivacySitemap

Published at Nov 29, 2024

HNSW vs. DiskANN

Explore for free

AI development for all developers, not just AI experts. Build your AI app with Tiger Cloud today.

A simple illustration of a navigable small world

Written by Haziqa Sajid

Vector search powers many artificial intelligence (AI) applications by enabling fast, accurate retrieval of similar items, whether for recommendations, language understanding, or image processing. Given its wide range of applications, it is important to optimize vector search for scalability. Hierarchical navigable small world (HNSW) and disk approximate nearest neighbor (DiskANN) are prominent algorithms in this domain. HNSW leverages a multi-layered graph to achieve high search speed and accuracy, while DiskANN is designed to handle vast datasets efficiently by operating primarily on disk.

This article will help you understand how HNSW and DiskANN work, compare their strengths and limitations, and decide which best suits your AI and data needs. We will:

  • Understand how HNSW and DiskANN algorithms function

  • Compare performance and use cases for each

  • Choose the right algorithm based on your system’s needs for speed and scalability

What Are Nearest Neighbor Search Algorithms?

Nearest neighbor search algorithms address the problem of finding vectors in a dataset that are most similar to a given query vector. In AI systems, data is often represented as vectors in a high-dimensional space, with the distance between vectors representing their similarity. This similarity is frequently measured using metrics like cosine similarity, which evaluates the angle between two vectors rather than their direct distance.

In practice, a user’s query is converted into a query vector, and the nearest neighbor search algorithm identifies stored vectors closest to this query vector, indicating high similarity.

Scaling challenges in nearest neighbor search

The scaling of nearest-neighbor searches presents significant challenges. Traditional or “greedy” algorithms calculate distances between the query vector and each vector in the database to determine the closest matches. While manageable for small datasets, this approach doesn’t scale well with large, AI-driven datasets where billions of vectors are common.

Because the query location is unpredictable, it’s not possible to pre-calculate or cache these distances. Instead, each new query requires fresh distance computations across all database entries, which is inefficient and limits the responsiveness needed in real-world applications. More advanced algorithms like HNSW and DiskANN are essential to achieve scalable, production-ready performance, as they offer optimizations tailored to handle large-scale vector search efficiently.

How HNSW Works

Hierarchical navigable small world (HNSW) is a graph-based nearest neighbor search algorithm designed to enhance search speed by creating an index structure based on the principles of the skip list. Inspired by the skip list’s layered probabilistic search, HNSW organizes data into a hierarchy of graph layers, where each layer has progressively denser subsets of data points. Before going into details of HNSW, let’s discuss its foundations:

1.  Skip lists: The foundation of layered search

At its core, HNSW builds upon the skip list search algorithm, a probabilistic approach to searching ordered data. Skip lists create random subset layers, allowing for increasingly refined searches. Like flipping through a book to find a specific page, skip lists let you make broad jumps first, then gradually narrow down to your target. Let’s see an example: 

image

An example of a skip list structure (Source)

To search for 71 in a skip list, start at the top left and move right, passing nodes like 31 since they're smaller. When you reach the end of a level, descend and repeat the process. Continue descending through the levels and moving right until you find 71. Here’s a guide if you are interested in learning more.

The beauty of skip lists lies in their simplicity. The algorithm can quickly navigate large datasets by creating multiple layers of the same data, with each upper layer containing fewer elements. While this method doesn't guarantee you'll find the exact match every time, it consistently achieves over 90 percent accuracy in returning the correct order of items.

2.  NSW: Graph-based navigation

The second key component is NSW (navigable small world), which tackles the challenge of finding nearest neighbors in vector space through graph-based navigation. Picture a vast network where each vector is connected to its nearby neighbors. The search process is intuitive: start at any point in the network, look at its connected neighbors, and move to whichever neighbor is closest to your query vector.

This process continues until you reach a point where none of the connected neighbors are closer to your query—this point is called a local minimum. While simple in concept, this approach provides an efficient way to navigate through vector space, especially when dealing with high-dimensional data. Here’s an example:

image

A simple illustration of a navigable small world

The search begins with node A as the predefined entry point. Node A selects node D, as the query is closer to D than to the nearer nodes C and B. At node D, the query is closer to node F. When no neighboring node is closer to the query than the current node, the search concludes, returning this final node as the result.

HNSW is an evolution of NSW that incorporates hierarchical multi-layer structures inspired by probability skip lists.

HNSW: The best of both worlds

HNSW brilliantly combines these two approaches by creating a hierarchical structure of NSW graphs. Imagine a series of layers containing its graph but with different information densities. The top layers are sparse, containing few vectors but allowing quick, broad searches. As you move through the layers, they become increasingly dense, enabling more precise searching.

The search process in HNSW is both elegant and efficient. You begin at the sparsest layer at the top, using the NSW graph search to find the closest vector at that level. Once you've seen this initial approximate match, you move down to the next, denser layer. Instead of starting from scratch, you begin your new search from the position you found in the layer above. This process repeats, with each layer refining your search further until you reach the bottom layer.

HNSW hierarchical layers speed up the search by quickly narrowing down the relevant area; dense lower layers refine the results for accuracy. Though fast and efficient, HNSW requires significant memory to manage multiple layers and maintain neighbor connections.

How DiskANN Works

DiskANN represents an innovative approach to approximate nearest neighbor search that challenges the conventional wisdom about ANN indices requiring main memory storage. While most ANN algorithms focus on in-memory performance, DiskANN introduces a novel architecture that enables efficient index storage on SSDs while maintaining competitive search performance.

The Vamana algorithm: A new graph-based approach

At DiskANN's core lies the Vamana algorithm, which takes a distinct approach to building navigable graphs compared to other methods like HNSW. While most graph-based algorithms start sparse and gradually add edges, Vamana begins with a dense random graph and employs an iterative pruning process to optimize it:

  1. Initialize with a random graph having more edges than necessary

  2. For each point in the dataset:

    • Perform a greedy search to find the current point's nearest neighbors

    • Use a "robust pruning" procedure to remove unnecessary edges while maintaining search efficiency

    • Add backward edges to ensure connectivity

  3. Repeat the process twice, with different distance thresholds, to optimize local and long-range connections.

image

Progression of the graph by the Vamana indexing algorithm (Source)

This pruning-based approach allows Vamanato to balance graph diameter (which affects search depth) and degree (which affects memory usage) better than traditional methods. Vamana was chosen for DiskANN because it builds a flat graph, which performs better with disk storage than a hierarchical structure. 

With a flat graph, the exact location of each node’s neighbors can be pre-determined, making information retrieval faster and more efficient despite the slower nature of disk storage. This structure minimizes the performance loss typically associated with accessing data stored on disk.

Disk-based storage architecture

DiskANN's key innovation is its ability to operate efficiently from SSD storage rather than requiring the entire index to be loaded in memory. This is achieved through several clever design choices:

  1. Clustered indexing: DiskANN partitions data into overlapping clusters using k-means clustering. Each data point belongs to multiple clusters, ensuring connectivity for search algorithms.

  2. Compressed vectors in RAM: Stores compressed representations of vectors in RAM, while full-precision data is stored on SSDs, allowing fast initial comparisons in memory.

  3. Beam search: DiskANN’s Beam Search retrieves neighborhood data from SSD in small batches, reducing read latencies by grouping nearby data access requests.

  4. Caching frequently accessed data: Commonly accessed nodes are cached in RAM to minimize repeated SSD accesses, further enhancing speed.

  5. Full-precision re-ranking: After identifying top candidates using compressed data, DiskANN re-ranks results using full-precision data from the SSD, ensuring accuracy without extra read overhead.

DiskANN's ability to operate from SSD storage represents a significant advancement in making ANN search more accessible and cost-effective at scale. While it may require more complex implementation and tuning compared to pure in-memory solutions like HNSW, the reduced memory requirements make it particularly valuable for:

  • Large-scale production systems where memory costs are a concern

  • Applications requiring billion-scale vector search on commodity hardware

  • Scenarios where maintaining multiple indices in memory is impractical

The trade-off between slightly increased query latency and dramatically reduced memory requirements makes DiskANN an attractive option for many real-world applications. This is especially true for applications handling massive datasets that would be prohibitively expensive to serve entirely from memory.

Comparing HSNW and DiskANN

Now that we’ve explored both algorithms, let’s summarize their key points and compare them side by side in a table.

HNSW vs. DiskANN: A comparison

Feature

HNSW

DiskANN

Speed

Low latency, with fast in-memory access.

Low latency, utilizes SSDs efficiently to manage large datasets.

Accuracy

Achieves over 90 % accuracy with high recall.

Achieves over 90 % accuracy with high recall.

Scaling

Scales well for sizable datasets, especially in RAM.

Scales well for massive datasets, leveraging SSDs for storage.

Complexity

Built on existing techniques, it is easier to implement.

Requires more layered optimizations for effective performance.

Compute

High memory requirements, more RAM-dependent.

Optimized for SSDs, reducing RAM dependency and costs.

What Is Right for You?

Both HNSW and DiskANN offer excellent vector search performance, though each is better suited for different needs:

HNSW use cases

  • Quick to scale: if you need vector search up and running quickly, HNSW is easier to implement, making it ideal for projects with tight timelines.

  • Standard infrastructure: HNSW operates efficiently on typical hardware without additional configuration, which avoids complex setups.

  • Memory-first approach: HNSW optimizes RAM usage, so it suits projects prioritizing in-memory speed over cost, particularly for mid-sized datasets.

  • Cost flexibility: if compute costs aren’t an issue, HNSW’s RAM requirements are manageable, providing strong performance without strict cost constraints.

DiskANN use cases

  • Compute efficiency: DiskANN’s design optimizes memory by leveraging SSDs, reducing RAM requirements, which is ideal for cost-sensitive projects.

  • Designed for massive data: DiskANN is a solid choice when dataset sizes are too large for RAM, offering high performance on SSD storage.

  • Advanced optimization potential: DiskANN enables complex configurations that can reduce costs over time—perfect for teams that can invest in longer-term optimization.

  • Memory-to-disk transitions: It is suitable for organizations anticipating large data growth, allowing compute to shift from memory to SSD storage efficiently.

Alternatives to HSNW and DiskANN

Timescale has optimized DiskANN for PostgreSQL with pgvectorscale, focusing on SSD storage and accurate filtering for scalable, fast vector searches. Standard DiskANN relies on in-memory storage, which becomes costly for large datasets, and retrieval accuracy can degrade with post-filtering.

Key Innovations in pgvectorscale:

  • SSD optimization: Traditional vector search algorithms require storing large data in RAM, which is costly. By integrating DiskANN, pgvectorscale allows vector data to be stored on SSDs, significantly lowering storage costs and maintaining high-speed search by reducing random memory access.

  • Streaming retrieval: HNSW-based systems often faced accuracy issues when filters didn’t match pre-fetched results. Streaming DiskANN enables continuous retrieval, ensuring accurate filtering by fetching items until the desired results are met, overcoming the “ef_search” limitation.

  • Statistical Binary Quantization (SBQ): Existing quantization techniques, like binary quantization (BQ), needed better accuracy. SBQ improves this by using a two-bit encoding for lower dimensions, enhancing recall and performance by enabling better differentiation and efficiency, especially for datasets with fewer dimensions.

These techniques collectively enable Timescale’s PostgreSQL extension to perform on par with specialized vector databases, enhancing affordability and compatibility with PostgreSQL’s ecosystem.

Conclusion

HNSW and DiskANN are highly efficient nearest-neighbor search algorithms, each excelling in different contexts. While their performance is similar in benchmarks, slight differences give each an edge depending on your needs. Timescale enhances your choice by integrating PostgreSQL's power and solving traditional indexes' limitations.

Discover more about Timescale's stack for AI and vector data and explore pgvectorscale to build scalable AI applications (GitHub ⭐s welcome).

Learn more

  • Vector Data Basics: HNSW

  • Understanding DiskANN

  • Streaming DiskANN: How We Made PostgreSQL as Fast as Pinecone for Vector Data

On this page

    Explore for free

    AI development for all developers, not just AI experts. Build your AI app with Tiger Cloud today.