I'm a legit postgres fanboy, my comment history will back this up, but the ops overhead and performance implications of trying to run PGvector as your core vector store for everything is just silly, you're going to be doing all sorts of postgres replication gymnastics to make up for the fact that you're using the wrong tool for the job. It's good for prototyping and small/non-core workloads, use it outside that scope at your own peril.

▲

alastairr 4 days ago | parent | next [-]

Interested to hear any more on this. I've been using pinecone for ages, but they recently increased the cost floor for serverless. I've been thinking of moving everything to pgvector (1M ish, so not loads), as all the bigger meta data lives there anyway. But I'd be interested to hear any views on that.

	▲	CuriouslyC 4 days ago \| parent \| next [-]
		It depends on your flow honestly. If you're just using your vectors for where filters on domain objects and you don't have hundreds of millions of vectors PGVec is fine. If you have any sort of workflow where you need low latency access to vectors and reliable random read performance, or where vector work is the bottleneck on performance, PGVec goes tits up.
	▲	whakim 4 days ago \| parent \| prev [-]
		At 1M embeddings I'd think pgvector would do just fine assuming a sufficiently powerful database.

▲

j45 4 days ago | parent | prev | next [-]

Appreciate the clarification. I have been using it for small / medium things and it's been OK.

The everything postgres as long as reasonably possible approach is fun, but not something I expect to last for ever.

▲

cpursley 4 days ago | parent | prev [-]

Guess I'm just not webscale™