kencho

thanks for the suggestion

there's a lot more in "setting up" than creating an account and a collection on pinecone or any other service

one use case we're handling right now is for a large online auction marketplace. they needed to automatically categorize 40,000 newly uploaded images per week. no tags, no metadata from the sellers, just raw photos. elasticsearch can't look at an image and tell you it's a vintage rolex or a mid-century lamp. they needed search that understands visual content, not text

that's the kind of problem where keyword search doesn't apply at all, no matter how good the engine is

you're completely wrong. we also added "make no mistakes" in the end

the article was aimed more at teams that don't have an existing postgres setup and are evaluating standalone vector databases from scratch. if you're already running postgres with pgvector, you're in a good spot

pgvector is great if you're already on postgres and only need text search. funny enough, Neon Postgres actually featured us in a case study about this exact topic. we replaced pinecone and rds with neon under the hood: https://neon.com/blog/vecstore-replacing-pinecone-and-rds-wi...

the gap shows up when you need image search, face search, or content moderation on top of text search. that's where a dedicated api makes more sense than rolling your own on postgres

fair point on the framing. we do use vector search internally, so calling it "not a vector database" is a stretch. the argument i was trying to make is more narrow: most teams evaluating pinecone or qdrant don't need to operate the vector layer themselves. they need search results from an api call. whether that api uses vectors, BM25, or hamsters under the hood shouldn't matter to them. i could have been clearer about that

No login required, the live demo is directly displayed in hero section and is fully interactive with real data

Exactly. We talk to teams every week who spent a month setting up pinecone or qdrant and then realize they just needed search that worked. The vector database became the default answer to every search problem because of the RAG hype cycle, even when the actual need is way simpler

Hello, the demo searches 10,000 paintings using semantic search, so you can type things like "dark forest with fog" or "people dancing at a party" and it actually finds relevant results even though none of those words appear in the metadata

The underlying product is Vecstore, a search api for text and images. the idea is you skip the whole embedding pipeline + vector database setup and just call an api. You send in your data, you search it. that's it

It also does reverse image search, face search, OCR (finding images by text inside them), and nsfw detection. all from the same api

Built with Rust