I have been a happy user of the Vector database Pinecone, which provided me with a truly 'serverless' experience.
I only needed to sign up, get an API key, and then pay for the usage of my applications.
Unfortunately, Pinecone decided to change their pricing model as announced in their email 'Important pricing update: minimum usage fee' 🤯
From 1st of September, all users - regardless of how extensive your actual use is - need to pay a minimum of US$ 50 per month.
Not ideal for me, since I generally managed to keep my bills under US$10 - by storing only the most essential data in the Vector DB (embeddings only and not the document content).
Needless to say, I was not very pleased and decided to migrate away from Pinecone for the main application I use a Vector DB for: AI Auto Relation for Notion.
As I assumed, I wasn't the only one facing this issue and quickly found the helpful Reddit thread: Pinecone’s new $50/mo minimum just nuked my hobby project - what are my best self-hosted alternatives?
I think the best alternatives from this conversation with everyone with less than US$50 per month of Pinecone costs are:
- Self hosted Postgres with pgvector
- Self hosted Chroma
- Fly.io 'managed' Postgres (with pgvector)
- Chroma Cloud
I was looking for a truly serverless solution; where I don't have the overhead of managing another server and my costs scale up linearly based on my usage - starting at $0.
As far as I could establish in my research Chroma Cloud is the only solution that provides this.
So I went ahead and changed the vector database for my Notion integration to Chroma Cloud.
Here everything I found out that could be of help for anyone interested in doing the same:
- I wasn't too impressed by the documentation. It all seemed a bit 'alpha' to me. However, there is of course the documentation of the Chroma open source project to complement this - but this I found to be not that great either. For example, I was looking for some information about the error codes the TypeScript SDK would return - so I could handle these - but wasn't able to find any information about this.
- The management interface seems to be more simplistic in comparison to Pinecone. However, it is able to help with the basics - e.g. see items in collection, do some basic searching and see some statistics.
- I understand Chroma does not scale as well as Pinecone. Thus, it could be advisable to split one 'Index' in Pinecone into multiple Chroma 'Collections'. I realised this only too late in my implementation. So I will hold my breath as to how well Chroma will perform for my solution (which only deals with a few thousand documents).
I just finished testing the new implementation today. As I learn more, I will update this post.
Otherwise, would be interested if anyone has found a better alternative.
Top comments (2)
Great write-up on the migration experience! The Pinecone pricing shift highlights a fundamental issue with current "serverless" vector DBs.
Your point about Chroma's scaling limitations is spot-on. Most alternatives today still run on server clusters behind the scenes, which creates the same economic pressures that pushed Pinecone to minimum pricing.
I recently analyzed this exact problem and concluded that the issue isn't just pricing—it's architectural. True serverless needs to be built from the ground up on serverless primitives (Lambda, S3) rather than just putting a serverless API on top of server clusters.
Would be curious to hear how your Chroma performance holds up with a few thousand documents. The scaling challenges you mentioned might surface sooner than expected.
(Full disclosure: I'm co-founder of LambdaDB, working on this serverless-native approach. Here's the architectural analysis if interested: lambdadb.ai/blog/serverless-databa...)
Thank you for your comment!
Great work on LambdaDB 👏
That gives me a good opportunity to look into when Chroma doesn't work out!