Summary
Requesting a way to reset or clear historical sync state for tables that were previously enabled and then disabled, so they can be treated as net-new tables without requiring a full historical resync (and associated MAR costs).

Background / Context
About a year ago, before a formal data team was in place, users at our company frequently enabled tables in Fivetran connectors, evaluated cost, and then disabled those tables shortly afterward. As a result, many tables were briefly synced but never actually used downstream.

Now, with a more mature data team and a renewed effort to expand our use of Fivetran, we are attempting to re-enable and fully utilize these tables.

Problem
When we attempt to sync these previously disabled tables, Fivetran requires a full historical resync. From our perspective, these tables are effectively “net new” because:

• They were never meaningfully used
• Any prior syncs were incomplete or short-lived
• The data was never leveraged downstream

However, the required historical resync results in a large spike in MAR, sometimes adding significant one-time cost (e.g., hundreds of millions of rows → substantial billing increase in a single month).

This creates friction in adopting additional tables and expanding our Fivetran usage.

Requested Feature
Introduce a mechanism to “reset” or “clear” the sync history for specific tables (or at the connector level), allowing them to be treated as net-new tables. Possible approaches:

• Option to mark a table as “new” and bypass historical backfill
• Ability to start syncing from the current point in time (forward-only sync)
• Connector-level reset for all currently unsynced tables
• UI or API control to drop prior sync state without requiring support intervention

Desired Outcome

• Avoid mandatory historical resync for tables that were previously enabled but not actually used
• Prevent large one-time MAR spikes when re-enabling tables
• Enable incremental, cost-controlled expansion of data coverage
• Improve flexibility for teams maturing in their Fivetran usage

Business Impact

• Reduces cost barriers to adopting additional tables
• Encourages broader and deeper use of Fivetran
• Aligns billing more closely with actual value derived from data
• Supports growing data teams that are revisiting earlier implementation decisions

Workarounds Considered

• Creating entirely new connectors (not always feasible or desirable)
• Accepting full historical resync costs (not scalable or cost-effective)
• Manually limiting table selection (does not solve underlying issue)

Additional Notes
This feature would be especially valuable for companies transitioning from early-stage usage (ad hoc syncing) to more structured, production-grade data practices.