IdeaWell

Project ideas from Hacker News discussions.

Pg_vectorsearch: An index that is faster than pgvector's IVFFlat and HNSW

Original Article

Hacker News Discussion

📝 Discussion Summary (Click to expand)

Three prevalent themes in the discussion

1. Performance claims and demand for benchmark transparency

Commenters repeatedly pointed to the advertised speed‑and‑memory gains and asked for clear benchmark numbers (QPS, precision/recall) to verify them.

  • “At 100 million vectors, PRISM achieved 6 ms query latency on a machine with 4× less memory than HNSW, with index builds over 20× faster.” – jascha_eng
  • “Shouldn’t you lead with your benchmarks if you’re fast? qps and precision/recall, please.” – esafak
  • “benchmarks are in the blog post and the benchmarking suite is also open sourced alongside it.” – jascha_eng
  • “with a fast backing disk, it's cut my postgres cost in half.” – EgregiousCube

2. Adoption barriers (PostgreSQL version, managed‑service support, alpha status)

Several users highlighted practical obstacles that could delay uptake, especially for those on older PG versions or relying on cloud‑managed databases.

  • “pg_vectorsearch requires Postgres version 18 or above. If you run PG versions below that you need to migrate your database first. Many legacy PG production environment are way dated on PG 14 or 15, migration is prohibitively high cost to just try this out.” – devy
  • “pg_vectorsearch shipped yesterday and it's obviously alpha. … it isn't on Azure's allowed-extension list or any other Hyperscale's managed PG instances' allowed extension list.” – devy
  • “Sadly if cloud providers don't offer it on managed postgres then not many people can use it…” – swe_dima
  • “Well you can always move to tiger cloud if you want it managed :)” – jascha_eng

3. Relationship to existing vector‑search extensions and architectural choices

The conversation frequently compared the new PRISM‑based extension to pgvector, pgvectorscale, and discussed why a separate project was started instead of contributing to pgvector.

  • “We deliberately chose a disk‑optimized design … portions of the graph could become unreachable, causing recall to degrade…. We came to believe they were a better foundation, and decided to start over.” – mfreed (author of pgvectorscale)
  • “When we built our first vector extension, pgvectorscale, we actually reached out to pgvector's author … At the time, their preference seemed to be to focus on the existing index types rather than expand the project in that direction.” – mfreed
  • “But one of the great things about open source and PostgreSQL's extension architecture is that these projects can coexist! pg_vectorsearch can work directly with pgvector's existing data types, so developers can use either index.” – jascha_eng
  • “I have used pgvector on an Azure DB … I am curious why they didn't just send a PR to the pgvector folks?” – curious_cat_163

These three themes capture the main thrust of the opinions expressed: excitement about performance promises, concerns about real‑world deployability, and debate over how the new extension fits into the existing PostgreSQL vector‑search ecosystem.

🚀 Project Ideas

VectorSearch Operator for Managed Postgres

Summary

  • Deploys and manages the pg_vectorsearch extension on existing managed PostgreSQL instances (AWS RDS, Azure Database for PostgreSQL, GCP Cloud SQL) via a Kubernetes operator or Terraform module.
  • Eliminates the need for self‑hosted PG 18 clusters and brings low‑RAM, fast vector search to teams locked into managed DB offerings.

Details

Key Value
Target Audience SaaS teams, startups, and enterprises using managed Postgres who want pg_vectorsearch without ops overhead
Core Feature Automated installation, version‑compatibility checks, rolling upgrades, and monitoring of pg_vectorsearch via Helm chart or Terraform provider
Tech Stack Go (operator SDK), PostgreSQL 18+, Helm, Terraform, Prometheus exporter
Difficulty Medium
Monetization Revenue-ready: SaaS subscription per instance (tiered by vCPU/storage)
#### Notes
- HN commenters lamented “If cloud providers don't offer it on managed postgres then not many people can use it…” (swe_dima) and “you have to migrate to a PG 18 self‑hosted.” (devy) – this operator removes that barrier.
- Enables discussion around extension lifecycle management and could be adapted for other PG vector extensions.

VectorTenancy – Multi‑tenant Vector Search with Built‑in Filtering

Summary

  • Provides automatic partitioning and row‑level security policies for pg_vectorsearch indexes per tenant/user/project, enabling efficient filtered vector search without manual schema work.
  • Core value: developers get tenant‑isolated, low‑latency similarity search with a single API call, solving the “how are people efficiently implementing tenant/user/permission scopes?” pain point.

Details

Key Value
Target Audience Multi‑tenant SaaS platforms, B2B apps, and internal tools that need per‑customer vector data isolation
Core Feature Declarative YAML/JSON config that creates partitioned tables, PRISM indexes per partition, and RLS policies; query wrapper injects tenant_id filter push‑down
Tech Stack PostgreSQL extensions (pg_vectorsearch, pg_partman), PL/pgSQL, Python/Node.js SDK, Docker
Difficulty Medium
Monetization Revenue-ready: Per‑tenant API calls or monthly active vectors pricing
#### Notes
- Commenters asked: “Does it support filtering though? … post filtering only” (Rapzid) and "I don't understand how people are efficiently implementing tenant/user/permission scopes with these indexes.” (Rapzid). This directly answers that.
- Enables discussion on combining RLS with vector indexes and could be extended to attribute‑based filtering.

VecTime – Recency‑Biasing Wrapper for pg_vectorsearch

Summary

  • Adds configurable time‑decay scoring to vector similarity queries, allowing users to blend recency with semantic relevance without costly hacks.
  • Core value: Simple SQL function or query builder that applies exponential decay based on timestamp column, addressing the “how are people doing recency biasing with vector databases?” frustration.

Details

Key Value
Target Audience Applications needing fresh results (news feeds, recommendation engines, logs) using pg_vectorsearch
Core Feature SQL function vector_time_score(embedding, ts, decay) that returns combined score; optional indexing on generated column for performance
Tech Stack PL/pgSQL, optional Python SDK, integrates with pg_vectorsearch PRISM index
Difficulty Low
Monetization Hobby
#### Notes
- Users complained: “All of our approaches are either expensive or super hacky.” (qeternity) regarding recency biasing. VecTime offers a lightweight, built‑in solution.
- Could spark discussion on hybrid scoring and be adapted to other vector stores.

Read Later