What is Fibery and how does it work?

The data model

Fibery's vocabulary is specific and worth learning before evaluating it. A Workspace is the account. It contains Spaces, each of which is a hub for one process such as software development, hiring or a CRM. A Space contains Databases, and a record inside a Database is an Entity. Fields describe Entities, Views display them, and Automations act on them. The API still uses the original names, type for Database and app for Space, so documentation and payloads read differently from the interface.

flowchart TD
  W[Workspace] --> S[Space]
  S --> D[Database]
  S --> V[View]
  S --> A[Automation]
  D --> E[Entity]
  D --> F[Field]
  D -. bidirectional relation .- D2[Another Database]
  V --> E
  A --> E

What makes the model different

Relations are the distinguishing feature. In Fibery they are always bidirectional and visible from both ends, they support one-to-one, one-to-many and many-to-many cardinalities, they cross Space boundaries, and a Database can be related to itself to build hierarchies of arbitrary depth. Formulas can traverse those relations and aggregate across collections, and Lookup fields surface a related Database's field in place. A Context View is a single view definition that automatically filters to whichever Entity the reader is currently inside, so one configuration produces a per-record view across an entire Database.

Views, documents and reports

The User Guide's canonical list of data views is Table, Board, List, Timeline, Gantt, Calendar, Feed, Map, Reports and Dashboard, with Documents and Whiteboards classified separately as content views and Forms as a third category. Fibery's marketing pages disagree with that list and with each other: the features page's views entry names only eight, with Forms, Charts and Dashboards listed elsewhere on that page as separate features, while the homepage names twelve and adds Gallery, which the documentation treats as a Board view showing image covers rather than a distinct type. Reports offer four visualisation types (chart, table, metric, pie), can draw on external sources including Google Sheets, Jira and MongoDB, and cannot traverse relations directly, so a Lookup field has to be materialised first.

Automation and access

Automations come in two forms, Rules that fire on a trigger and Buttons that a user clicks. JavaScript scripted actions are limited to the Pro plan and above. Permissions are granted at Space, Database and Entity level and are additive: access "is always extended and never overridden on a lower level of hierarchy". There are no field-level permissions, and the vendor states none are planned.

Where it sits

Fibery competes with Notion, Airtable, ClickUp and Linear. Its own comparison page argues that relations are first-class in a way they are not in Notion, and that Airtable's cross-base connections are weaker. Those are vendor claims. The pricing detail is covered in the Fibery pricing answer, and the head-to-head is in Fibery vs Notion.

Editor's Note: We run Automation Atlas's own editorial CRM on Fibery. Reading the schema through Fibery's API on 18 August 2026 returned 8 user-created Spaces and 34 Databases, built up over roughly a year without a migration. That is the model working as advertised. The honest caveat is the one Fibery itself publishes: the flexibility "comes with a cost", and in our workspace the cost showed up as permissions. Because Fibery has no field-level permissions, we had to split commercially sensitive fields out into a separate linked Database rather than hiding a column, which is a schema change forced by an access-control limit. Budget design time for that, not just for the data model. — Rafal Fila, ShadowGen