Meridian Line is building four retrieval-backed applications — charter clauses, customs filings, port circulars and maintenance logs — each needing its own index with different schemas and filters. The platform team is deciding how many Vector Search endpoints to provision. What is the appropriate reasoning?
Select an answer to reveal the explanation.
Short Explanation
Think of the endpoint as the serving box and the indexes as the things you put in it: you can host several indexes on one endpoint. Start with a shared endpoint, then split it if isolation or capacity needs call for it.
Full Explanation
In Databricks Vector Search, an endpoint supplies serving compute, and multiple indexes can use the same endpoint. For Meridian Line’s four applications, a shared endpoint is a sensible starting point; provision separate endpoints deliberately if an application’s traffic needs capacity isolation, or if you need separate blast radii or access boundaries. The claim that each endpoint is bound to one index at creation is incorrect: that one-to-one restriction does not exist and would add unnecessary cost and operational overhead. The claim that a workspace has a hard limit of one endpoint is also incorrect. Quotas can apply in practice, but they do not make exactly one endpoint the rule. The claim that Delta Sync indexes query their source Delta tables directly confuses the source with the serving path: the Delta table supplies data to the index, and the index is queried through a Vector Search endpoint, just like a Direct Vector Access index. Exam caveat: keep endpoint, index and source table distinct; they have separate roles and lifecycles. Practical check: confirm the indexes’ serving endpoint, then assess traffic, capacity and access boundaries before deciding whether to split it.