Meridian Line publishes notices to mariners a few times a week, and the port-operations copilot must reflect a new notice within roughly a day. The platform team is comparing sync modes for the Delta Sync index and wants the lowest ongoing compute cost that still meets that freshness need. Which configuration should they choose?

Delta Sync supports triggered and continuous sync. Continuous sync keeps a streaming pipeline running so changes reach the index within seconds to minutes, and its compute costs continue for as long as it runs. Triggered sync starts compute when a sync is invoked, processes changes since the previous run, and stops. Because Meridian Line publishes notices only a few times a week and the copilot needs updates roughly daily, a scheduled triggered sync meets the freshness requirement at lower ongoing compute cost. Continuous sync is not necessary just because scheduled runs might seem likely to leave the index permanently out of date: each run processes the changes accumulated since the last run. Adding a low-cost endpoint to continuous sync does not make that always-running compute as cost-effective, and triggered sync can capture deletes; both modes process Change Data Feed events. A nightly full rebuild is possible, but it re-embeds unchanged rows and discards the benefit of incremental processing, making it less cost-effective than triggered sync. Exam caveat: sync mode is a freshness-versus-cost tradeoff, so choose the least costly mode that meets the stated latency—not the fastest mode by default. Practical check: confirm the scheduled interval fits the freshness deadline and verify that a run applies updates and deletes made since the prior run.