I have long held the view that not all vector-based solutions should be collectively referred to as vector databases, although their capabilities can rival them in some respects. From my point of view, such as pgvector or Elasticsearch, they are both excellent and mature products that can indeed meet user needs well in specific scenarios.
When the amount of data is small, using Elasticsearch combined with scalar retrieval is enough to meet business scenarios. Alternatively, if your original data is completely stored in a relational database, then it is completely feasible to search hundreds of thousands or even 1 million data based on pgvector operations. But once the amount of data increases, you will find that many business scenarios will be limited by traditional database design and cannot scale well.
In fact, when discussing what capabilities a vector database provides, I think there are several key points that cannot be avoided, including algorithms, computing power, and scheduling. As a vector database, these aspects require special design.
One example I keep mentioning is that if you just want to perform nearest neighbor retrieval, you can write an ANN, and it may take less than 10 lines of code to achieve the nearest neighbor retrieval function you need. But the reason why everyone chooses not to do this is largely due to performance and cost factors. From this perspective, once performance, cost, and scalability are critical to you, many traditional databases may not be able to meet your needs.