A Delta Sync Vector Search index over Meridian Line's port-authority circulars table has been running fine for months, but a new set of circulars written to the table today never shows up in search results, even after waiting well past the usual sync delay. What is the most likely cause?
Select an answer to reveal the explanation.
Short Explanation
Delta Sync indexes ride on the table's Change Data Feed. If CDF gets turned off — schema changes can do that — the index has no way to hear about new rows, no matter how long you wait.
Full Explanation
A Delta Sync index depends on the source table's Change Data Feed to learn about inserts, updates, and deletes; if CDF is disabled on that table after the index was created — which certain schema-changing operations can do — the index loses its change stream and stops picking up new rows, with no error surfaced to the person writing new circulars. Re-enabling CDF (and typically re-syncing) restores the flow. There is no monthly sync cap tied to the embedding model endpoint; sync cadence is governed by the index's sync mode (continuous or triggered), not by any limit on the embedding endpoint itself. The claim about Direct Vector Access indexes ignoring rows after creation is both the wrong index type for this scenario — Direct Vector Access is updated via direct API calls, not by watching a Delta table at all — and not a real behavior; Direct Vector Access indexes accept upserts whenever the API is called, with no such creation-date cutoff. There is no fixed, undocumented nightly maintenance window that gates all Vector Search updates; sync timing is controlled by the configured sync mode, not a hidden platform-wide schedule. Exam framing: this is the operational failure mode behind the CDF prerequisite tested in index creation — knowing the prerequisite also means knowing what breaks when it's silently removed.