Postgres extension complements pgvector for performance and scale
1–10 of 26 posts
Re: Postgres extension complements pgvector for performance and scale
#2I’ve been using this since early this year and it’s been great. It was what convinced me to just stick to Postgres rather than using a dedicated vector db.
Only working with 100m or so vectors, but for that it does the job.
Re: Postgres extension complements pgvector for performance and scale
#3I’ve been using this since early this year and it’s been great. It was what convinced me to just stick to Postgres rather than using a dedicated vector db. Only working with 100m or so vectors, but for that it does the job.
Are you using a dedicated pg instance for vector or you keep all your data in a single pg instance (vector and non-vector)?
Re: Postgres extension complements pgvector for performance and scale
#4I’ve been using this since early this year and it’s been great. It was what convinced me to just stick to Postgres rather than using a dedicated vector db. Only working with 100m or so vectors, but for that it does the job.
Are you using a dedicated pg instance for vector or you keep all your data in a single pg instance (vector and non-vector)?
The biggest selling point to using Postgres over qdrant or whatever is that you can put all the data in the same db and use joins and ctes, foreign keys and other constraints, lower latency, get rid of effectively n+1 cases, and ensure data integrity.
Re: Postgres extension complements pgvector for performance and scale
#5I’ve been using this since early this year and it’s been great. It was what convinced me to just stick to Postgres rather than using a dedicated vector db. Only working with 100m or so vectors, but for that it does the job.
What kind of performance do you observe with what setup?
Re: Postgres extension complements pgvector for performance and scale
#6Earlier quoted context omitted.
Are you using a dedicated pg instance for vector or you keep all your data in a single pg instance (vector and non-vector)?
The biggest selling point to using Postgres over qdrant or whatever is that you can put all the data in the same db and use joins and ctes, foreign keys and other constraints, lower latency, get rid of effectively n+1 cases, and ensure data integrity.
I generally agree that one database instance is ideal, but there are other reasons why Postgres everywhere is advantageous, even across multiple instances:
- Expertise: it's just SQL for the most part - Ecosystem: same ORM, same connection pooler - Portability: all major clouds have managed Postgres
I'd gladly take multiple Postgres instances even if I lose cross-database joins.
Re: Postgres extension complements pgvector for performance and scale
#7Earlier quoted context omitted.
The biggest selling point to using Postgres over qdrant or whatever is that you can put all the data in the same db and use joins and ctes, foreign keys and other constraints, lower latency, get rid of effectively n+1 cases, and ensure data integrity.
I generally agree that one database instance is ideal, but there are other reasons why Postgres everywhere is advantageous, even across multiple instances: - Expertise: it's just SQL for the most part - Ecosystem: same ORM, same connection pooler - Portability: all major clouds have managed Postgres I'd gladly take multiple Postgres instances even if I lose cross-database joins.
Yep. If performance becomes a concern, but we still want to exploit joins etc, it's easy to set up replicas and "shard" read only use cases across replicas.
Re: Postgres extension complements pgvector for performance and scale
#8The linked blogpost is an interesting read, too, comparing well-tuned pgvector to pinecone:
Re: Postgres extension complements pgvector for performance and scale
#9Related discussion for pgvector perf: https://news.ycombinator.com/item?id=45798479
Re: Postgres extension complements pgvector for performance and scale
#10This is still unsupported in RDS, right?