Hi Carlos! First of all thank you for taking the time to evaluate Atlas Vector Search against the RCs of your application. I should be able to answer your questions:
We are in the process of rolling out a deployment options page within the vector search documentation that should make this more clear, but essentially you have the option of deploying separate cluster nodes specifically for the vector search workload. This allows for greater resource isolation, higher availability and more cost-effective scaling compared to the default state where search and database resources are coupled on the base MongoDB cluster (referred to as “coupled architecture”).
You’ve cited the low-cpu entry point for dedicated search nodes that are recommended for vector search, referred to on the pricing page as “vector search nodes,” but when testing queries prototyping you don’t need to start on dedicated search nodes and can run solely on the base MongoDB cluster, including the free M0 tier, shared M2/M5 tiers, as well as the dedicated M10+ tiers, as we support zero-downtime migration from the coupled architecture. Here is a page listing some limitations of search when running on free or shared clusters that might be helpful.
Thank you for the feedback on this example being complex. We definitely want to make sure there is an easier way of jointly considering lexical and vector search results, as we have a whole set of capabilities around lexical search that go well beyond what Weaviate supports. We have something in the works on this, and I will make sure to follow up when it’s available on this forum.