In a new write-up from Farallon Geographics, Taking a Stroll Down the Road(map), Alex Wuthrich details how the June 2025 release of Arches Version 8 introduced important new changes, specifically graph versioning for greater flexibility in data model development. Excerpts have been cross-posted below; visit the Farallon blog, ON LOCATION, for the full text, direct quotes from senior developers, and instructional videos.
Graph Versioning Refines Data Modeling
Data models set the foundation for everything that Arches does and shape the data that you store in the system to meet your business vertical.
In previous versions [of Arches], changing a data model required a heavy-handed approach: delete all data, update the model, and re-import everything. Even though the Bulk Data Manager preserved your data during this process, it was far from efficient—especially during early project stages when teams are still shaping their models …This changes in Version 8 with the introduction of Graph Versioning.
What is Graph Versioning?
Graph Versioning opens the doors for greater flexibility in model development. Now, published graph models can be edited without having to delete resource data. In fact, v8 allows administrators to make many model improvements without requiring the model to be unpublished … However, it’s common that model shapes will need to be updated during system development.
With v8, when a graph designer or a system administrator wants to adjust the structure of a resource model, they may navigate to the “Manage” button in the top left corner of the graph designer UI and click “Draft an Update” within the dropdown. This will enter the user into a new, unsaved instance of the model where changes can be applied, thereby creating a new version of a model.
Graph Versioning allows edits to model shapes even when tile data exists within a model’s node groups. This is a big shift from previous versions. As the structure of the model changes, so too does the form of the data within it. Version 8 introduces a new safeguard here: when changes are ready to be published, the system prompts users to decide whether they’d like to automatically migrate existing data to match the updated structure.
This option offers a powerful new degree of control—but it also requires some thought. Not every change should be migrated automatically, especially in more complex or data-heavy environments. Whether automatic migration is appropriate depends on the stage of your project and the complexity of your model, with consideration of the benefits and risks.
Ad-Hoc Changes: Quick and Flexible Projects
For teams in the early stages of implementing an Arches project, data models are often still evolving. In these cases, the focus is usually on identifying gaps in the data structure, making incremental improvements, and building out node groups as needs become clearer. Completeness of the dataset isn’t critical yet, and any changes made are typically additive—such as introducing new attributes or minor node group adjustments.
Arches will keep track of the various iterations that model goes through via a model’s Version History. Users can attach notes that describe the changes between versions and can easily switch between existing versions with the click of a button. Furthermore, Arches will automatically adapt your data to meet the version that you choose!
In this kind of ad-hoc editing, automatic migration is not only safe but extremely useful. By allowing data to conform automatically to updated models, project teams can move quickly, test the impact of changes, and continue refining their models without redoing setup work or reloading data. This ability to iterate is a huge improvement for small projects and for larger teams still working through the early cycles of data loading and transformation.
What Developers Need to Know
For mature projects—especially those with complex, deeply-nested resource models or large volumes of production data—there are serious considerations when thinking about editing a schema structure. These systems often support formalized workflows or domain-specific packages like Arches for Science or Arches for HERs. For example, the forthcoming Arches Lingo application gives the Arches community more granular control over building authoritative hierarchies, a process that requires not only complex resource models but also supports the extensibility of those models to meet dynamic needs. Making changes to these models often involves restructuring or removing elements, which in turn can affect associated business data.
Version 8 introduces deeper backend capabilities that improve traceability and consistency in graph management. Chief among them is the addition of composite identifiers. Each resource model now has not just a static graph UUID, but also a newly introduced version UUID. Version identifiers are also assigned to resource instance records to indicate which model version was used to create them. This allows developers to target specific versions of a model, compare them, and code more confidently against expected structures.
This is important because automatic migration introduces risk. If nodes or branches are removed from the model, any associated data tiles will be lost in the migration process … That’s why, in these cases, automatic migration should be avoided. Instead, developers can write custom migration logic that ensures existing tile data is properly mapped to new structures without the stress of trying to understand the schema structure. This gives them the control needed to preserve and transition critical information …
While Graph Versioning immediately benefits resource modelers and administrators, its longer-term significance may be even greater for developers. By offering a more structured, version-aware backend, Arches 8 lays the foundation for a new generation of Arches-powered applications … [and] allows the Arches platform to evolve without breaking what’s already working. It gives community developers tools they can rely on to efficiently grow their projects in scale or complexity to meet business needs.
