4 ms·
Many of the concerns in the article could be addressed by standing up a separate PG database that's used exclusively for vector ops and then not using it for yo
by throwway120385 1y ago
Many of the concerns in the article could be addressed by standing up a separate PG database that's used exclusively for vector ops and then not using it for your relational data. Then your vector use cases get served from your vector DB and your relational use cases get served from your relational DB. Separating concerns like that doesn't solve the underlying concern but it limits the blast radius so you can operate in a degraded state instead of falling over completely.
- SoftTalker 1y agoI've always tried to separate transactional databases from those supporting analytical queries if there's going to be any question that there might be contention. The latter often don't need to be real-time or even near-time.
- samus 1y agoThat is a workaround and precisely the point the author makes. It increases operational complexity and creates a divide between records in the vector DB and the relational DB.
- anentropic 1y agoBut if you do that, why use Postgres for the vector db?