If I wanted to do that I'd use PgVector, since I use Postgres for just about everything. There'd need to be a really good reason to go with a specialized DB.
You can do everything with PostGres: Full-text search, but there are better engines for it: Elastic, Meilisearch, etc. right?
You can also store JSON into Postgres, but you should better use MongoDB for NoSQL purposes, right?
The reason for this is: dedicated tools are always better, faster, and more feature-rich.
Depends. Polyglot persistence has the benefit of letting you use the "best tool for the job" for each job but that benefit can fall apart if you have cross-cutting concerns. If you need to query across different storages you often end up compromising on several of the initial benefits (e.g. performance from passing data between storages or resource use and consistency from duplicating critical data).
For example, you could store your graph data in Neo4J and your document data in MongoDB but good luck doing graph queries that need to access the document data. OR you could use something like Tiger or Arango that's a graph database that can also store data other than pure edges.
Postgres is quite good as a JSON store btw.
> You can also store JSON into Postgres, but you should better use MongoDB for NoSQL purposes, right?
It's a common folklore at this point that Postgres is sometimes a better document store than most NoSQL databases (including Mongo), see for example this which is also at the front page of HN today, https://news.ycombinator.com/item?id=35544499
Yes, most people are perfectly OK with just one car.
Specialists need special cars, but general public most of the time is ok with a family car.
PgVector might not be production ready, but it doesn't mean that for most of the situations Postgres's full-text, JSON, GIS, Graph-walking, Queues etc. isn't good enough with advantages of using just one database. There's a new category of problems when you let your data be in multiple places. On top of that, when you go full into Pg, with things like PostgREST, you can sometimes end up with a very minimalistic backend.
My understanding is that this mostly due to the default settings that pgvector uses (nprobes = 3) and not due to the usage of IVF. The recall would improve significantly with better defaults. This of course would also increase the latency of vector searches, but that is the trade-off of using IVF instead of HNSW (worse latency at high recall, but much lower storage/memory costs).
Yeah, right, dedicated tools my ass.