[HN Gopher] Postgres extension complements pgvector for performa...
___________________________________________________________________
Postgres extension complements pgvector for performance and scale
Author : flyaway123
Score : 102 points
Date : 2025-12-24 22:04 UTC (6 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ricw wrote:
| I'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.
| pqdbr wrote:
| Are you using a dedicated pg instance for vector or you keep
| all your data in a single pg instance (vector and non-vector)?
| ComputerGuru wrote:
| 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.
| dalberto wrote:
| 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.
| throwaway7783 wrote:
| 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.
| nicholasjarnold wrote:
| Postgres supports the Foreign Data Wrapper concept from
| SQL/MED. If you configure this you can do joins across
| instances, even!
|
| https://www.postgresql.org/docs/current/postgres-fdw.html
| ricw wrote:
| All in one of course. That's the biggest advantage. And why
| postgres is great - it covers virtually all standard use
| cases.
| esafak wrote:
| What kind of performance do you observe with what setup?
| ricw wrote:
| Depends on the query and I don't have exact numbers of the
| top of my head, but we're talking low 100ms range for
| something pgvector itself wasn't able to handle in a
| reasonable amount of time.
| isoprophlex wrote:
| The linked blogpost is an interesting read, too, comparing well-
| tuned pgvector to pinecone:
|
| https://www.tigerdata.com/blog/pgvector-vs-pinecone
| aunty_helen wrote:
| Related discussion for pgvector perf:
| https://news.ycombinator.com/item?id=45798479
| tacoooooooo wrote:
| the main issue with pgvectorscale is that it's not available in
| RDS :(
| omg2864 wrote:
| Yes, RDS seems to really hold PG back on AWS, with all the
| interesting pg extensions getting released now (pg_lake). It
| is a share I can't move to other PG vendors because it is a
| pain in the ass to get all privacy, legal docs in order.
| calderwoodra wrote:
| Yes, the InfoSec advantages of using RDS are very real,
| especially in B2B Enterprise SaaS.
| mrinterweb wrote:
| I'm considering hosting a separate pg db just to be able to
| access certain extensions. I am interested in this extension
| as well as https://wiki.postgresql.org/wiki/Incremental_View_
| Maintenanc... (also not available on RDS). Then use logical
| replication for specific data source tables (guess it would
| need to be DMS).
| mmmeff wrote:
| This is still unsupported in RDS, right?
| tacoooooooo wrote:
| correct afaik :(
|
| https://github.com/timescale/pgvectorscale/issues/113
| jascha_eng wrote:
| We have a lot of happy customers that moved from rds to tiger
| cloud if you think pgvectorscale is interesting to you and you
| don't want to self host pg.
|
| But yes big cloud providers move slow in adopting extensions.
| jascha_eng wrote:
| Combined with our other search extension for full text search
| these two extensions make postgres a really capable hybrid search
| engine: https://github.com/timescale/pg_textsearch
| ldng wrote:
| I'm not how you'd combine the two; care to give us a quick
| outline ?
| jascha_eng wrote:
| We have docs on how to do hybrid search here:
| https://www.tigerdata.com/docs/use-
| timescale/latest/extensio...
|
| Essentially you combine the pgvector score and the bm25 score
| to hopefully get better results.
| dmarwicke wrote:
| does this actually fix metadata filtering during vector search?
| that's the thing that kills performance in pgvector. weaviate had
| the same problem, ended up using qdrant instead
___________________________________________________________________
(page generated 2025-12-30 23:00 UTC)