Sync a database both ways

Both ways, Filarr and the external database can change the same row. The sync compares each cell with the last value both sides agreed on, and decides.

A scheduled sync is offered from Solo. You need a key that can write to the source (see External database connectors).

The rule, cell by cell

the source changed?	Filarr changed?	what happens
no	no	nothing
yes	no	Filarr takes the source's value
no	yes	the source takes Filarr's value
yes, to the same value	yes	nothing; the reference moves on
yes	yes, to different values	a conflict: the column's policy decides

"Filarr changed" means the cell itself was written since, not that the row was touched: a device coming back from offline with an old change is never silently lost.

The four policies

At the Direction and frequency step, under "When the same cell changed on both sides since the last run", you choose one for the whole sync, and if needed another per column (A policy per column). None is ticked by default: the screen does not let you go on until you choose.

policy	on a conflict	example
The source wins	Filarr takes the source's value; Filarr's goes to the journal	a customer's city, kept by the shop
Filarr wins	the source takes Filarr's value; the source's goes to the journal	an internal note you write in Filarr
The latest change wins	the one that changed last wins	a column both sides rarely change at the same time
Ask me	nothing is written; the cell waits for your decision	a status that matters

"The latest change wins" needs a change marker that is a date. Limit: the marker dates the ROW, not the cell (another column changed later in the source makes it win too), and it compares the clocks of two machines.

The "Ask me" queue

A conflict on an "Ask me" column enters a queue: Filarr keeps its value, the source keeps its own, and the rest of the row and of the database keeps syncing. The database says so at the top: "3 conflicts to settle".

The conflicts panel lists each one (row, column, the source's value, Filarr's value). For each: Keep Filarr's value or Take the source's. Or all at once: Settle all for Filarr, Settle all for the source. The decision goes, encrypted, to the runner, and starts a run.

• A decision holds for the values you saw. If a side changed since: "The value changed since your decision: this conflict needs settling again."
• Two people settle the same conflict: the first decision received applies; the other one reads "Already settled by … on …".
• Queue full: "N conflicts are waiting for your decision, and M more are waiting for room in the queue. Those cells don’t sync meanwhile."
• Changing the policy of a column that has waiting conflicts asks you, without choosing for you: Settle the waiting conflicts with the new rule, or Keep them to settle by hand.

You settle from the desktop app or the web. A synced database is kept in the large database storage, which the current mobile app does not open yet: the phone shows neither the database nor its conflicts.

Lost values

Each lost value (a conflict, a replaced value, a decision) is kept in the sync's journal. The screen that shows this journal and lets you Restore a value is not in the app yet. For a column that matters, prefer Ask me: nothing is replaced there without your decision.

Rows deleted on one side, changed on the other

A separate choice, also with no default: Deletion wins, The change wins (the row is kept), or Ask me. In the queue, such a row is settled with Keep the row or Delete it.

What the sync does not guarantee

• On a conflict, one side loses (to the journal) or the cell waits: it is your choice.
• While a conflict waits, the software reading the source sees its own value.
• Airtable, Google Sheets and Notion cannot write "only if the value has not changed": a window of less than a second remains, where a change made at that moment in the source can be overwritten (and kept in the journal). D1, PostgreSQL, MySQL and Supabase do not have this window.
• A source that rounds or reformats a value (a date, a number): the sync reads it again and takes the source's value; a column that changes this way at every run stops being sent, and the state says so.

Good practices

• A stable row key, never reused.
• A marker kept by the database itself (a trigger that updates updated_at at each change).
• An access key limited to the tables you need.

Learn more

• Feed a database from an external database
• The rule in detail, with its guarantees: github.com/filarr-work/filarr-gate.