Safety & undo
Read-only by default, and everything undoes
Most database tools assume you meant it. FireFetch assumes you might not have — and makes being wrong cheap.
Change history — undoing a bulk operation
screenshot pending · 1400×880
Every database starts read-only
Connect a project and you can browse everything and change nothing. Writes are enabled per database, deliberately, by you. Production stays locked while you work in staging, because they are separate databases and the switch is per database.
This is not a UI nicety that a stray keystroke can slip past. The gate is enforced in the application core, where the writes are actually issued — the interface merely reflects it. Scripts, bulk operations, the MCP server and inline table edits are all subject to the same check.
Every write records the write that reverses it
When FireFetch changes a document, it stores the inverse operation alongside it. Undo is not a re-fetch and overwrite — it is the precise counter-write, which is why it works for operations that a naive implementation could never reverse.
A mistyped field
Restored to its previous value, with its previous type.
A deleted field
Put back, rather than set to null.
A bulk update across 4,000 documents
Reversed as one step from the history panel.
A find-and-replace
Reversed as one step, including partial string edits.
An unsafe undo is refused, not forced
If someone else changed a field after your write, undoing yours would throw their change away. FireFetch detects this and refuses that undo rather than silently winning. You are told what conflicts, and you decide.
The same principle governs ordinary edits. FireFetch sends the document's last-known update time as a precondition, so a save that would overwrite a change made since you loaded the document fails loudly instead of succeeding quietly. Last-write-wins is a data-loss bug wearing a convenience costume.
Your values survive the round trip
A safety feature that rarely gets named as one: FireFetch does not coerce your data. Editing a document in a tool that parses everything as a JavaScript number is how an int64 quietly loses its last digits.
- 1.0 stays a double — It does not silently become the integer 1.
- Integers beyond 2⁵³ keep every digit — No precision is lost on the way through.
- Bytes stay bytes — Not a base64 string that looks similar.
- Microsecond timestamps keep their microseconds — Including through export and re-import.
You can see what you are spending
Firestore bills by operation, and it is genuinely easy to page through a large collection and rack up reads without noticing. FireFetch keeps a running count of reads and writes for the session in the status bar, with a breakdown of where they went.
Note that this counter is about your Google Cloud bill, not ours — FireFetch never meters reads.
Status bar — session read and write counter
screenshot pending · 1200×480