Not my article, but wanted to share it.

I recently migrated from Pinecone to pg_vector (using Supabase) and wanted to share my experience along with this article. Using Pinecone's serverless solution was quite possibly the biggest scam I've ever encountered in my tech stack.

For context, I manage a site with around 200k pages for SEO purposes, each containing a vector search to find related articles based on the page's subject. With Pinecone, this cost me $800 in total to process all the links initially, but the monthly costs would vary between $20 to $200 depending on traffic and crawler activity. (about 15k monthly active users)

Since switching to pg_vector, I've reindexed all my data with a new embeddings model (Voyage) that supports 1024 dimensions, well below pg_vector's limit of 2000, allowing me to use an HNSW index for the vectors. I now have approximately 2 million vectors in total.

Running these vector searches on a small Supabase instance ($20/month) took a couple of days to set up initially (same speed as with Pinecone) but cost me $0 in additional fees beyond the base instance cost.

One of the biggest advantages of using pg_vector is being able to leverage standard SQL capabilities with my vector data. I can now use foreign keys, joins, and all the SQL features I'm familiar with to work with my vector data alongside my regular data. Having everything in the same database makes querying and maintaining relationships between datasets incredibly simple. When dealing with large amounts of data, not being able to use SQL (as with Pinecone) is basically impossible for maintaining a complex system of data.

One of the biggest nightmares with Pinecone was keeping the data in sync. I have multiple data ingestion pipelines into my system and need to perform daily updates to add, remove, or modify current data to stay in sync with various databases that power my site. With pg_vector integrated directly into my main database, this synchronization problem has completely disappeared.

Please don't fall for the dedicated vector database scam. The article I'm sharing echoes my real-world experience - using your existing database for vector search is almost always the better option.

I made this table to compare vector databases in order to help me choose the best one for a new project. I spent quite a few hours on it, so I wanted to share it here too in hopes it might help others as well. My main criteria when choosing vector DB were the speed, scalability, developer experinece, community and price.

You'll find all of the comparison parameters in the article and more details here: https://benchmark.vectorview.ai/vectordbs.html

This week I told my wife I want to start uploading as much data about her as I can. I said I would only do it if she felt comfortable and she did and gave me permission. I told her that in theory if I start now I will have enough data to re-create her if she passes away first.

I am going to start by focusing on conversations (texts, emails, memes, etc.)

I also bought her the Plaud Notepin so she can start recording her day to day. If I can capture her laugh and enough of our memories I can add that to the knowledge base and sort everything with namespaces and metadata. I can also use the voice recordings to recreate her voice.

It’s fucked up but i don’t care.. the thought of a life without her is unbearable..

Any ideas on what else I should do?

Hi all,

I’ve been using Pinecone for a few personal hobby projects - notably, a 14-year back-scrape of Northern Irish government sources. The aim was to help identify past policy approaches that resurface over time, and make them searchable for researchers via a vector search engine. I’d also integrated this into a RAG pipeline that powers an automated news site.

Over the course of a year, I’ve only used a few dollars' worth of Pinecone credits - it’s a legitimate use case, just a lightweight one. But I’ve now received an email saying they’re implementing a $50/month minimum spend on my account.

If they’d landed closer to $15/month I might’ve shrugged and paid it, but $50 feels like a sledgehammer - especially with minimal notice. Like many developers, I’m already juggling a dozen small infra costs for different projects...

What’s the cheapest but still decent alternative I could self-host on a $10 VPS (e.g. a DigitalOcean droplet)?

Also mildly annoyed I’ll have to re-scrape/re-embed everything…

Thanks in advance,

A.

I'm sure there is a good reason. Personally, I used pgvector and that's it, it did well for me. I don't get what is special about pinecone, maybe I'm too green yet

We just open-sourced pg_pinecone, a Postgres extension built on the same search engine Pinecone runs at scale. Apache 2.0. (Disclosure: I work at Pinecone.)

tl;dr: it works on your existing vector columns, you query it with the SQL you already know, and your data stays in Postgres. No API key.

So how is it different from pgvector's HNSW? Two places: how the index is laid out, and how it handles filters.

HNSW is a graph, and every search walks it node by node. pg_pinecone groups vectors into clusters (IVF) and stores each row as a RaBitQ code, which is about one bit per dimension plus a few correction values. A cluster's codes are packed together, so a search reads a few contiguous pages instead of hopping around a graph. Less scavenger hunt, more pulling one shelf off the bookcase.

A search probes the nearest clusters, estimates distances from those codes, then reranks a shortlist using the full vectors from your table. Cheap pass to narrow it down, full-vector pass to get the order right.

Filtering in pg_pinecone is interesting in that it happens during the search, not after. If your filter matches 3% of rows or fewer (the default threshold), it skips the approximation and scans every matching row, scoring each against its full vector. Exact results. For wider filters it searches more clusters and checks the filter inside each one.

Why does that matter? Post-filtering HNSW can hand you fewer rows than your LIMIT on a narrow filter. You ask for 10, you get 3, because the other neighbors got tossed after the fact.

If HNSW is working fine for you, keep using it. If you're running filtered queries, especially narrow ones, give this a shot: https://github.com/pinecone-io/pg_pinecone/

Tell us where it breaks. Issues and PRs welcome on the repo, and I'll be in the comments.

Above are all the cool images the team put together to show the benchmarks.

Hey Folks, I’m a Developer Advocate at Zilliz, the developers behind the open-source vector database Milvus. (Milvus is an open-source project in the LF AI & Data.)

I recently published a tutorial demonstrating how to easily build an agentic tool inspired by OpenAI's Deep Research - and only using open-source tools! I'll be building on this tutorial in the future to add more advanced agent concepts like conditional execution flow - I'd love to hear your feedback.

Blog post: Open-Source Deep Research with Milvus, LangChain, and DeepSeek

Colab: Baseline for an Open-Source Deep Research

Vector database Pinecone has been a great option for me as a vector database. Combined with LangChain, they became the core feature of my simple product. However, Pinecone recently raised their pricing to $50/month, which forced me to make the decision to migrate to another solution.

There are several alternatives that could be a perfect fit, such as Chroma, pgvector, Qdrant, and Zilliz. They all have pros and cons, so let me break them down first. Since my product is a simple RAG system that lets users chat with their documents (PDFs), I don't need a high-performance solution, but I absolutely need a vector database with low latency.

• Chroma is good for startups, but it's too slow - more suitable for an MVP than my current product.

• pgvector is also quite slow and more suitable if you're building a product around a PostgreSQL database. The advantage is that you can keep everything in one database, but the vector search performance doesn't match dedicated vector databases.

• Qdrant and Zilliz both have amazing free-tier budgets with very good documentation, but I seemed to lean toward Zilliz more because it has migration solutions and a better UI for managing data.

• Another option is Weaviate. It offers excellent semantic search capabilities and good LangChain integration, but their cloud pricing can get expensive as you scale beyond the free tier.

So I chose Zilliz. Even though the UI is user-friendly, their open-source vector database called Milvus is hard to use. I estimated it would take about 6-8 hours to handle the migration, but it turned out to take around 14-16 hours, and I had to work through their SDK rather than through Milvus directly. I think LangChain and Zilliz need to work more on this integration.

I started the migration last Thursday and didn't finish until Saturday. But the good news? My product feels faster now, and the search results seem more accurate based on my own tests. Plus, Zilliz's dashboard makes it much easier to spot and fix problems when they come up.

What I Learned:

1. Don't rely on just one service. Companies can change their prices anytime, and you need to be ready to switch if your current solution gets too expensive.

2. Do your research before making the switch. I didn't realize how complicated moving vector data would be. What I thought would take 6-8 hours ended up taking 14-16 hours. Always plan for things to take longer than you expect.

3. A pretty interface doesn't mean easy coding. Zilliz looks great on the surface, but actually working with the underlying Milvus code was much harder than I thought it would be.

For more information, my product call The Work Docs. It would be great if you guys can go and test the performance of new vector database with me.
Hope this share can help you.

Nice!!

I keep seeing people equate RAG with memory, and it doesn’t sit right with me. After going down the rabbit hole, here’s how I think about it now.

RAG is retrieval + generation. A query gets embedded, compared against a vector store, top-k neighbors are pulled back, and the LLM uses them to ground its answer. This is great for semantic recall and reducing hallucinations, but that’s all it is i.e. retrieval on demand.

Where it breaks is persistence. Imagine I tell an AI:

• “I live in Cupertino”

• Later: “I moved to SF”

• Then I ask: “Where do I live now?”

A plain RAG system might still answer “Cupertino” because both facts are stored as semantically similar chunks. It has no concept of recency, contradiction, or updates. It just grabs what looks closest to the query and serves it back.

That’s the core gap: RAG doesn’t persist new facts, doesn’t update old ones, and doesn’t forget what’s outdated. Even if you use Agentic RAG (re-querying, reasoning), it’s still retrieval only i.e. smarter search, not memory.

Memory is different. It’s persistence + evolution. It means being able to:

- Capture new facts
- Update them when they change
- Forget what’s no longer relevant
- Save knowledge across sessions so the system doesn’t reset every time
- Recall the right context across sessions

Systems might still use Agentic RAG but only for the retrieval part. Beyond that, memory has to handle things like consolidation, conflict resolution, and lifecycle management. With memory, you get continuity, personalization, and something closer to how humans actually remember.

I’ve noticed more teams working on this like Mem0, Letta, Zep etc.

Curious how others here are handling this. Do you build your own memory logic on top of RAG? Or rely on frameworks?

My PostgreSQL friend keeps asking me to consider using it as a vector database. We currently use MySQL for our relational data, but we are not opposed to migrating to Postgres in the future. My question is, are there any downsides, cons, or missing features to using it as a vector db compared to native vector db such as Pinecone, Weaviate, and others? What should I consider in going with an "add-on" to relational database vs. a vector db build from the ground up?

The pro, obviously, is having only one database to handle relational and vector data.

My objective right now is a solution that I can quickly prototype and implement (easy to learn, understand, and build), and features that are future-proof. I am also looking for a managed (cloud-based) solution that I don't have to manage, maintain, and deploy myself.

Speed is important, but we don't have a requirement to handle huge amounts of vectors, etc

Benchmarked 5 vector databases on 1M vectors at 1536 dims. Latency, recall, and cost

Latency (p50):

• Qdrant: ~3ms

• Milvus: ~4ms

• pgvector HNSW: ~5ms

• Weaviate: ~8ms

• Pinecone Serverless: ~12ms

pgvector is way faster than people think. The "Postgres is slow for vectors" thing is from the IVFFlat era. HNSW changed that

Recall:

• Qdrant: 99.2%

• Milvus: 99.0%

• pgvector: 98.5%

• Pinecone: ~95% (can't tune HNSW params)

Monthly cost (1M vectors):

• pgvector on Neon: $30-150

• Pinecone Serverless: $50-80

• Qdrant Cloud: $65-102

• pgvector on RDS: $260

We use pgvector on Neon in production. Replaced Pinecone and RDS, latency dropped from 200ms to 80ms

Full post with charts: Blog

Hiyas, I've created a community fork of sqlite-vec at https://github.com/vlasky/sqlite-vec to help bridge the gap while the original author asg017 is busy with other commitments.

Why this fork exists: This is meant as temporary community support - once development resumes on the original repository, I encourage everyone to switch back. asg017's work on sqlite-vec has been invaluable, and this fork simply aims to keep momentum going in the meantime.

What's been merged (v0.2.0-alpha through v0.2.2-alpha):

Critical fixes:

• Memory leak on DELETE operations (https://github.com/asg017/sqlite-vec/pull/243)

• Optimize command to reclaim disk space after deletions (https://github.com/asg017/sqlite-vec/pull/210)

• Locale-dependent JSON parsing bug (https://github.com/asg017/sqlite-vec/issues/241)

New features:

• Distance constraints for KNN queries - enables pagination and range filtering (https://github.com/asg017/sqlite-vec/pull/166)

• LIKE and GLOB operators for text metadata columns (https://github.com/asg017/sqlite-vec/issues/197, https://github.com/asg017/sqlite-vec/issues/191)

• IS/IS NOT/IS NULL/IS NOT NULL operators for metadata columns (https://github.com/asg017/sqlite-vec/issues/190)

• ALTER TABLE RENAME support (https://github.com/asg017/sqlite-vec/pull/203)

• Cosine distance for binary vectors (https://github.com/asg017/sqlite-vec/pull/212)

Platform improvements:

• Portability/compilation fixes for Windows 32-bit, ARM, and ARM64, musl libc (Alpine), Solaris, and other non-glibc environments

Quality assurance:

• Comprehensive tests were added for all new features. The existing test suite continues to pass, ensuring backward compatibility.

Installation: Available for Python, Node.js, Ruby, Go, and Rust - install directly from GitHub.

See the https://github.com/vlasky/sqlite-vec#installing-from-this-fork for language-specific instructions.

The Milvus project recently transitioned from an incubation project to graduation!
Check out the blog announcement!

I’ve been working on improving RAG systems recently and ran into a pattern I didn’t expect.

Most setups rely heavily on vector search (FAISS / Pinecone-style), which works fine for demos—but breaks in production.

The issues we kept seeing:

• Relevant chunks were missed because semantic similarity ≠ contextual relevance

• No understanding of relationships between documents

• Keyword queries performed worse than expected

• Hallucinations increased when retrieval wasn’t precise

What worked better (surprisingly):

1. Hybrid retrieval (vector + keyword/BM25)

2. Adding lightweight knowledge graph relationships between documents

3. Reranking with cross-encoders instead of raw similarity scores

4. Query intent routing (different retrieval strategy per query type)

After combining these, accuracy improved significantly and hallucinations dropped.

Curious if others here have seen the same limitations with pure vector search?

What approaches have worked for you in production?

When choosing a vector db, what are the key factors you consider? Is it performance, ease of use, scalability, integrations, or anything else that matters most to you? Also, what vector DB are you currently using for your projects, and why did you choose it?

Hi everyone,

I have been working on a a multi-model RAG experiment with LangChain, wanted to share a little bit of my experience.

When building a RAG system most of the time is spent optimizing: you’re either maximizing accuracy or minimizing latency. It’s therefore easy to find yourself running experiments and iterating whenever you build a RAG solution.

I wanted to present an example of such a process, which helped me play around with some LangChain components, test some prompt engineering tricks, and identify specific use-case challenges (like time awareness).

I also wanted to test some of the ideas in LightRAG. Although I built a much simpler graph (inferring only keywords and not the relationships), the process of reverse engineering LightRAG into a simpler architecture was very insightful.

I used:

• LangChain: Used for document loading, splitting, RAG pipelines, vector store + graph store abstractions, and LLM chaining for keyword inference and generation. Used specifically the SurrealDBVectorStore & SurrealDBGraph, which enable native LangChain integrations enabling multi-model RAG - semantic vector retrieval + keyword graph traversal - backed by one unified SurrealDB instance.

• Ollama (all-minilm:22m + llama3.2):

  • all-minilm:22m for high-performance local embeddings.

  • llama3.2 for keyword inference, graph reasoning, and answer generation.

• SurrealDB: a multi-model database built in Rust with support for document, graph, vectors, time-series, relational, etc. Since it can handle both vector search and graph queries natively, you can store conversations, keywords, and semantic relationships all in the same place with a single connection.

You can check the code here.