Meridian Line stores its charterparty clause chunks in a Unity Catalog Delta table that a nightly job updates as new charters are signed. The charter-desk team wants the retrieval index for its clause assistant to pick up those new charters without anyone writing embedding or upsert code. Which Databricks Vector Search index type fits this requirement?
Select an answer to reveal the explanation.
Short Explanation
Think of a Delta Sync index as a subscription and a Direct Vector Access index as a shopping trip. You get automatic refreshes from the Delta table with Delta Sync, while Direct Vector Access waits for vectors to be pushed through the API. Since your clauses are already in a Delta table and you want to avoid writing plumbing, Delta Sync fits.
Full Explanation
Databricks Vector Search offers two index types, and the choice depends on where the data lives and who keeps the index current. A Delta Sync index uses a source Delta table in Unity Catalog; Databricks handles embedding and upsert and keeps the index aligned as rows change. That meets Meridian Line’s requirement: clause chunks are already in a governed Delta table, and the team does not want to write embedding or upsert logic. A Direct Vector Access index accepts client writes, but it does not automatically stay aligned with the Delta table; it must be populated through the API. A Direct Vector Access index populated by a scheduled REST upsert loop can work, but it makes the charter-desk team build and operate the very embedding or upsert plumbing it wants to avoid. The claim that Delta Sync cannot use a table written by a job invents a restriction: Delta Sync requires a Delta source with Change Data Feed available, not a streaming writer. For the exam, remember that the source table needs a primary key and Change Data Feed enabled before you create a Delta Sync index. As a practical check, verify both settings on the Unity Catalog table and confirm that the nightly job updates that table.