Data Objects in Pimcore

Data Objects in Pimcore are how you model structured product and master data. They turn Pimcore into a full PIM.

This guide explains the whole model for Pimcore 12 (Platform 2026.1). You will meet every building block, from classes to select options.

One thing changed for everyone. The legacy ExtJS “classic” admin no longer ships in 2026.1, so the old “Settings > Data Objects” route is gone.

Everything now lives in the modern React-based Pimcore Studio. This post follows that path throughout.

What is a Pimcore Data Object?

A class is the blueprint. It defines the fields a record will hold, such as name, SKU, price, and image.

A Pimcore Data Object is one record built from that blueprint. Think of the class as the mold and the object as a single casting.

So Data Objects in Pimcore are structured records, each an instance of a class. Pimcore stores every object in MySQL and builds a typed PHP model for it.

You need no OOP knowledge to use them. Pimcore turns data modeling into a point-and-click job inside Studio.

Where Data Objects in Pimcore live now

Every building block sits under one Studio menu. You reach it from the left navigation.

Follow this path:

1. Open Data Management in the left navigation.
2. Expand Data Model Definitions.
3. Pick the entity you need.

The menu lists eight entities. These are Classes, Field Collections, Object Bricks, Classification Store, Select Options, Quantity Values, Bulk Export, and Bulk Import.

The next sections walk each building block in turn. Together they define the shape of your Data Objects in Pimcore.

Classes: the blueprint for every object

A class defines the field structure that every object of that type will share. It is the first thing you build in any Pimcore project.

You create a class under Data Model Definitions > Classes. Studio opens a Create New Class Definition dialog for a name and a unique identifier.

Inside the editor you add fields from ten data-component families. These cover Text, Numeric, Date, Select, Media, Relation, Geographic, CRM, Structured, and Other.

Those families supply every field type your Data Objects in Pimcore will ever need. You mix them freely to match your model.

Saving a class does two things at once. Pimcore builds the MySQL tables and generates the typed PHP model, so no coding is required.

Want the full walkthrough? See our guides to creating a class and a data object and to class settings.

Field Collections: repeatable rows of fields

A Field Collection is a reusable set of fields you can add many times to a single object field. It models a one-to-many list of structured entries.

Picture a product with a list of specifications. Each row holds its own sub-fields, and you add as many rows as you need.

You define a Field Collection under Data Model Definitions > Field Collections. On a class, a Field Collection field then declares its “allowed types”, so it only accepts the collections you choose.

Pimcore stores each Field Collection in its own tables, separate from the base object. That keeps repeatable data clean and queryable.

Object Bricks: optional field groups per class

An Object Brick is a reusable group of fields you attach to specific classes. Treat it as an optional attribute set or a mixin.

Unlike a Field Collection, a brick is not a repeatable list. It is an add-on block that you bind to a class and a container field.

Take a Car class as an example. An “engine” brick holds cylinders, capacity, and power, and you add it only where an engine applies.

Each brick declares which class and field it can join. Pimcore stores brick data in its own object_brick_* tables per class.

Classification Store: dynamic attribute sets

A Classification Store is one field that holds a large, dynamic set of key/value attributes. You organize those attributes into Keys, Groups, and Group Collections.

The big win is flexibility. Admins manage the keys at runtime, so different categories get different attributes without a new class each time.

Say shoes need Size and Color while electronics need Wattage and Frequency. One Classification Store field serves both, and each key carries its own type.

This is the data-driven cousin of Object Bricks. Bricks are developer-defined field groups, while a Classification Store is admin-managed at runtime.

Quantity Values: a number with a unit

A Quantity Value stores a number paired with a unit. Think 5 kg, 200 mm, or 60 W.

Units live in one central place. Each unit carries an abbreviation, a long name, a base unit, and a conversion factor.

You manage units under Data Model Definitions > Quantity Values. A field on your class then references them, so weights and dimensions stay consistent.

This keeps measurement data structured. Downstream systems read a clean value plus a known unit, not a free-text string.

Select Options: reusable option sets

Select Options are a newer building block for reusable dropdown values. You define an option set once and reference it from many fields.

Each option carries a value, a label, and a name. Studio even generates a PHP enum for the set, so your code stays type-safe.

Without this, every Select field repeats its own hardcoded options. With Select Options, you maintain one central list under Data Model Definitions > Select Options.

Reuse is the point. Update the shared set once, and every field that references it stays in sync.

How Pimcore stores a Data Object

Saving a class creates several MySQL tables. You rarely touch them, but the map helps when you debug.

Pimcore uses four table types per class:

1. object_<id> — the base row for each object.
2. object_store_<id> — the stored field values.
3. object_query_<id> — values tuned for grid and listing queries.
4. object_relations_<id> — the links between related objects.

These tables hold every one of your Data Objects in Pimcore. Pimcore keeps them in sync with the class definition on each save.

One modern detail matters. Pimcore 12 dropped the old o_ column prefix from the base objects table, so its columns are now id and key, never o_id or o_key.

Prefer to build in code? Define classes in PHP, then run pimcore:build:classes and pimcore:deployment:classes-rebuild to sync everything.

Where Data Objects in Pimcore go next

A data model is only the start. Each object becomes a feed for the systems around your business.

Pimcore Data Hub exposes your objects over GraphQL. A storefront or app can then query them directly, field by field.

Connectors carry the same structured data to each platform. Our team documents a full sync in the Pimcore Magento 2 connector guide.

Multi-language content rides along too. The Pimcore DeepL bundle translates localized fields in place.

Conclusion

You now know the full picture of Data Objects in Pimcore for the latest Studio. Each building block models a different shape of data.

Classes hold the core fields. Field collections, object bricks, classification stores, quantity values, and select options each extend that model in their own way.

Ready to connect that model to a storefront or ERP? Talk to the Webkul Pimcore team about a connector that moves your objects where they need to go.