Welcome to a new era in the Arches Project world! With the release of Arches Version 8 on June 15th, the platform has taken a major leap forward—introducing powerful new features, refined architecture, and a more formal framework for developing and managing applications. We’re calling it: the dawn of the Arches Application Developer.
At Farallon, we’re excited to unpack what’s new in V8. From architectural improvements to business-friendly modeling tools, we’ll walk you through what’s changed, why it matters, and how these changes will benefit different users. In this post, we’re taking a deeper dive into the cornerstone of this release, Graph Versioning. If you are interested in understanding how this release supports more efficient and higher quality implementations, and don’t need the technical underpinnings, check out our companion post!
You can explore the full list of features here!
The Big One: Graph Versioning Refines Data Modeling
If you’ve ever set up Arches for a project, you already know the importance of getting your data models right. 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, 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 for the developers running these migrations, who often must deal with loosely defined schematic structures to map tile data into.
We’ve heard from the community—and experienced ourselves many times over at Farallon— about the frustrations of updating resource models and lacking the proper clarity to ensure data flows properly into new versions. Rob Gaston, Senior Web Developer at Farallon, recalls the feedback he has seen from the Arches community around project liftoff:
“For those folks trying to get a project up and running, we’ve often heard people express that changing models can be a pain point. ‘I want to just be able to iterate on my models in peace and then update the data and rerun an ETL.’ Is a common theme. There’s probably nobody in the Arches Community who has set up an Arches application from scratch who won’t recognize that this is a gap.”
This changes in V8 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 (we’ll explore the specific attributes of this in a later post). 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.
Furthermore, Graph versioning gives users the capability to edit their resource models while tile data exists in node groups—a departure from versions past. Changing the structure of a graph also changes the form of the data that resides within it. When changes are published, users are presented with the option to automatically migrate existing data to the new model. However, this option introduces an important consideration: not all changes should be migrated automatically. Depending on the project stage and complexity of the data model, users will need to weigh the risks and benefits.
Structural Changes: A Ledger of Progress
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.
With graph versioning, Arches can allow developers to evolve application models in a managed, programmatic way. As of V8, Arches now catalogs new model shapes as versions within a model’s “Version History”. This allows developers to access a ledger of publications, providing a means for tracking how models have evolved. Previously, there was nothing to support tracking model changes or reverting changes.
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—a scenario Rob refers to as a “lossy migration.” 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.
According to Rob, this is a crucial part of what makes Graph Versioning a powerful new tool: “it’s about the formalism that this creates around managing changing graph shapes, which facilitates the ability to reliably code against models or, at least as an application developer, throw exceptions when you know the models are not the models that you expect.”
Looking Ahead: The Arches Application Developer Era
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.
With the release of new Arches Applications on the horizon—including tailored packages for specialized domains—developers will be better equipped to build, customize, and extend functionality. They’ll also be able to do so with greater confidence that their applications are anchored to stable, identifiable versions of resource models.
This formalism, combined with the flexibility introduced on the frontend, 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.
Version 8 is not just about making things easier—it’s about setting up a more resilient ecosystem for long-term innovation. As the Arches community continues to grow, so too do the opportunities for developers to contribute their own applications, packages, and enhancements. Farallon is excited to see where this next chapter takes us, and we’re committed to supporting the community as it explores what’s possible with this new architecture.
What’s Next
Over the coming weeks, we’ll be diving deeper into other features introduced in Version 8, including holistic data management tools and some best practices around planning data migrations. We’ll also be sharing updates on upcoming Arches Applications and what they mean for different sectors.
In the meantime, we encourage you to start exploring Graph Versioning and thinking about how it could change the way you build, manage, and scale your Arches projects.
Have questions or want to share your experience with V8? We’d love to hear from you.
