Skip to main content
This is 2026.9 documentation. Coverage here is incremental: a page exists only where 2026.9 differs or is newly documented. For any other topic, switch to Current (2026.8 and earlier) in the version selector.
If you write scripts, notebooks, or small automations against Speckle object data, 2026.9 changes the shape of that data. Before 2026.9, the Data Schema is a directed tree of Collections and DataObjects, with Proxies at the Root Collection for shared resources. 2026.9 replaces that tree-and-Proxy graph with two things working together: a columnar property store for querying and aggregation, and an explicit relational layer for how elements relate. This page is the conceptual model for that change. Dates, compatibility mode, Automate SDK bumps, and who must act are on Data model migration for developers. For a compact before-and-after table, see Compare 2026.8 and 2026.9. There is no Proxy type anywhere in 2026.9 bundle data - not renamed, not kept around as a compatibility shim. No RenderMaterial, Level, Group, Definition, InstanceProxy, or InstanceDefinitionProxy object exists in the format. Everything a Proxy used to carry is now either a row in the columnar property store or an edge in the relational layer. Detached references go with them. Before 2026.9, assigning one object to a detached property on several parents stored it once and left a {"speckle_type": "reference", "referencedId": ...} pointer in each, resolved through the parent’s __closure. A bundle has neither: there is no closure, and no reference object type. An object that several others need is an edge in the relational layer, and a value that several objects share is one row each in the property store.
Standard connectors, SDKs, and APIs keep working with published data. This page matters if your script assumes the nested object graph or unpacks Proxies itself, rather than going through supported accessors. See Data model migration for developers.

​
What’s different

Project → Model → Version remains the address of a published snapshot. That addressing system is unchanged. What lives at a version is what changed. What a version points at also changed. There is no root object to start from; see Where version metadata lives in 2026.9 for what carries the version’s units, source application, and model-wide facts instead.

​
Columnar property store

Before 2026.9, a wall’s parameters live on the DataObject (and on nested geometry in displayValue). To total area or filter by type, a script walks the tree and reads nested fields. In 2026.9, object identity stays stable (applicationId from the source application). Attributes are stored as rows in a columnar property store: each row is one object, one property path, and one value. That layout is what makes filter, group, and aggregate cheap on large models, instead of walking a reconstructed graph.
Treat property paths as the public names of attributes (for example a category or type name), not the JSON shape of a received Base object. Nested dictionaries belong to the object graph of 2026.8 and earlier.
This page does not document a query API or SQL surface. Use supported SDK accessors for the data you already read. If a tool assumes the old object-graph shape and breaks, follow Migration guidance.

​
Relational layer

Proxies solved overlapping membership without duplicating geometry: a wall could sit on a level, use a material, and belong to a group by appearing in each Proxy’s objects list. The collection tree was still the only hierarchy a traversal walked. 2026.9 puts those links beside the property store as typed relations. Containment, connectivity, systems, and materials are richer than today’s Proxies: they include host-to-child containment, MEP and spatial connectivity, and system membership, not only shared resources at the root. The named relation types, and how they compare to Proxies, are on Relations in 2026.9. Speckle Intelligence uses both halves. It looks up properties on objects, and it follows relations for questions such as what connects to what and what contains what. That behaviour is in the comparison table.

​
Publishing creates the version on the server

Before 2026.9, a publish is a client-side act in two steps. You assemble one root object, put every object under its elements (with Proxies beside them at the root), send that graph to get its id, then create a version that points at the id. The root object is both the data and the anchor, and the client decides the moment the version exists. In 2026.9 there is no root to assemble and no version to create. A bundle builder holds objects, grouping containers, and relations side by side, with no top. send3 / Send3 opens a model ingestion, which reserves a version id, uploads the bundle under that id, and completes the ingestion. The server creates the version at that point, in one step. Three habits change with this:
  • There is no elements to fill. Membership is a relation such as IN_COLLECTION or ON_LEVEL, set on the object, not a list on a parent.
  • Version metadata is given up front. The source application and message go to the ingestion when it opens, not onto a root object at the end.
  • The version exists only after ingestion completes. A publish returns a reserved id. Wait for the version before you query, link, or receive it.
The full sequence, and where each piece of metadata now lives, is on Where version metadata lives in 2026.9. If you build a producer without a Speckle SDK, the file set, wire sequence, and bundle rules are on Building integrations in 2026.9.

​
What a script should assume

1

Keep using the version address

Resolve project, model, and version the same way you do today. The snapshot you point at is still a version. The outcome is a published model you can read.
2

Identify objects, then properties

Key objects by source identity (applicationId). Read attributes from the columnar property store by property path. The outcome is values you can filter or aggregate without walking nested Base fields.
3

Follow typed relations for topology

Use named relations for level, material, containment, connectivity, and systems. The outcome is membership and connectivity without unpacking a Proxy’s objects array. See Relations in 2026.9.
If you maintain tooling that reads Speckle data more directly than the standard SDK or API surface, and it breaks against the new format, pin to 2026.8 while you update. Compatibility mode for ACC sync and drag-and-drop uploads ends 1 November 2026. Details: Data model migration for developers.

​
What is not on this page

Connector-specific dumps, SDK before-and-after samples, and a SQL or local query API are separate work. Until those pages exist, use the Data Schema for the object graph of 2026.8 and earlier, and the developer migration page for who is affected in 2026.9.

​
FAQ

Yes, for versions published in today’s tree-and-Proxy format. Use Data Schema overview, Concepts, and Proxy schema for that graph. Use this page for 2026.9 bundle data.
No. Existing connectors, SDKs, and integrations continue to work with published data. Watch Automate functions that process versions from a connector that only writes the new bundle format: bump the SDK dependency. See Who’s affected.
That reconstruction is the object graph of 2026.8 and earlier. On 2026.9 data, containment and shared resources live on the relational layer, and properties live in the columnar store. A missing nested elements tree or Proxy objects list is expected. Update the script to identify objects, read property paths, and follow named relations — or pin to 2026.8 until you can.
See Relations in 2026.9. That page maps today’s Proxies to typed edges such as ON_LEVEL, SUBELEMENT, CONNECTS_TO, and IN_SYSTEM.
No. There is no RenderMaterial, Level, Group, Definition, InstanceProxy, or InstanceDefinitionProxy object in the format - not hidden, not deprecated-but-present. If your code checks for a Proxy type or a root-level *Proxies array on 2026.9 data, it will find nothing, not an empty compatibility stand-in. See Relations in 2026.9 for what carries that information now.
Last modified on September 24, 2026