Meridian Line's charter-clause index needs to reflect new contracts within minutes of being written to the Delta table, since brokers cite clauses the same day a charterparty is signed. Which Vector Search sync-mode choice fits, and what is the trade-off against the alternative?
Select an answer to reveal the explanation.
Short Explanation
You want continuous sync for clauses brokers need almost immediately: it keeps the index nearly real-time, but uses compute even when nothing changes. Triggered sync costs less, but refreshes only when you call it manually or on a schedule, so it may leave new contracts missing until then.
Full Explanation
Delta Sync indexes support continuous sync, which watches the source table’s change feed and updates the index with low latency. The trade-off is ongoing compute consumption, even when no new rows arrive. Triggered sync updates only when explicitly invoked, manually or through a scheduled job; it costs less but leaves the index stale between triggers. Because brokers need same-day clauses within minutes, continuous sync better fits Meridian’s near-real-time freshness requirement, with higher steady-state cost. The claim that triggered sync refreshes instantly after every row change and incurs no compute cost reverses the actual behavior: automatic change-feed updates are continuous sync’s role, and ongoing operation uses compute. Continuous sync is not limited to Direct Vector Access indexes; it is a Delta Sync mode. Direct Vector Access indexes are updated through direct API calls, not either sync mode, so switching to direct writes and rebuilding is not required. The embedding model’s context window controls how much text a single embedding call can consume; it does not control index freshness. Exam caveat: sync-mode choice is a latency-versus-cost trade-off within configuring Vector Search endpoints and indexes. Practical check: confirm the index uses Delta Sync and compare its required update latency with the cost of keeping continuous sync running.