Hi Fibery team! Here is a “food for thought” suggestion regarding data safety and UX.
In Google Sheets, we have Version History, which allows us to instantly see and restore the state of the entire document at any specific point in time.
Sometimes, a user (or an automation/script error) can accidentally mess up hundreds of records, change a complex formula, or delete relations across the whole database. Currently, we have to check the Activity Log for each entity or ask support for a manual backup restore.
It would be amazing to have a Snapshot where an admin could:
Preview how the Database looked 2 hours ago or 2 days ago.
Restore the state of a specific Database/Space.
I understand that with Relations it’s technically much harder than in a flat spreadsheet, but for a “Single Source of Truth” platform, this level of “Undo” at the database level would provide immense peace of mind.
Yes, I’m familiar with the Activity Log, but it addresses a different scale of problem. Here is why the current system maybe isn’t enough for database management:
The “Granularity” Issue: Activity Log allows for restoring items one by one. If a script or an accidental batch edit messes up 500+ records, it is physically impossible to restore them manually via the Activity Log. It will be great if we will have a way to roll back the entire state of a Database to a specific timestamp (e.g., “Yesterday at 2 PM”).
The “Relations” Chain Reaction: When data is messed up globally, restoring individual entities doesn’t always correctly re-stitch the complex web of Relations. A full Database Snapshot would ensure that all connections are restored exactly as they were.
Rich Text vs. Data Fields: While documents have Version History, standard Database fields (Numbers, Enums, Dates) do not have a dedicated “Restore Version” panel for the whole table.
Activity Log is great for “Who deleted this task?”. But for “Someone just broke large part of workspace with a bad automation,” it wull be great to have a Point-in-Time Recovery (PITR) or Space-level Snapshots.
In Google Sheets, I can undo a catastrophic mistake in 2 clicks. In Fibery, a similar mistake currently requires a huge manual backup restore.
I think it is unlikely that we would implement a ‘time machine’ option for databases, since it would massively grow the amount of data that would need to be stored for each workspace.
It would also have some serious technical challenges, e.g. if an entity in db 1 was linked to an entity in db 2 a couple of days ago, what should happen if I try to restore db 1 to that point, but the entity in db 2 no longer exists? What if the db had a formula field that utilised a field/relation which no longer exists?
Maybe at some point (in the far future) we will add support for users to create a limited number of ‘system restore’ points, but supporting database snapshots for every individual database for multiple points in time would likely be unsustainable.
It makes total sense why a continuous “Time Machine” is a technical and storage nightmare for a relational system like Fibery. The scenarios you mentioned—broken relations with non-existent entities or “ghost” fields in formulas—perfectly illustrate why this is much harder than a simple Undo in Excel.
Really good idea of “System Restore Points” that you mentioned. Even if a full automated history is unsustainable, having a way to create a manual checkpoint would be a lifesaver.
For example, an admin could create a restore point before:
Running a major data migration;
Executing a complex new automation script;
Significantly changing the database schema.
Even if these restore points were limited in number or user can save it not in fibery, it would provide immense peace of mind during “high-risk” structural work.
Yes, I’m familiar with the Activity Log, but it addresses a different scale of problem. Here is why the current system maybe isn’t enough for database management: