Data Panda brings your Pimcore data together with the data from the rest of your business. From one place, we turn it into dashboards, automations, AI workflows and custom apps your team uses every day.
Pimcore was founded in 2013 in Salzburg, Austria, and is built on PHP, Symfony and MariaDB. It started life as a GPL-licensed open-core platform and grew into the broader positioning it uses today: a single modeller for product information, master data, customer data, digital assets, content and commerce. In January 2025 the company moved the core from GPL to a proprietary POCL license with version 12, which is why the community-driven OpenDXP fork exists alongside it. Funding so far: Auctus Capital Series A in 2018 and a 12 million dollar Series B led by Nordwind Growth in 2022.
Where Akeneo is a PIM built around the product record, Pimcore is a broader data-and-experience platform where product data is one class among several. The class-and-attribute system is defined by you per tenant, which means a Pimcore tenant can hold products, customers, vendors, orders, marketing assets, 3D files and CMS documents side by side in the same object tree. That flexibility is the product. It is also the reason a Pimcore export looks different at every client, and the reason a warehouse view on top of it has to read the class definitions before it can read the data.
What a Pimcore tenant ends up asking the warehouse: where did the product record drift from the ERP, which DAM asset is orphaned from its SKU, which customer master has two linked company records that should be one, and which commerce page references a 3D model nobody has maintained in six months.
Completeness and drift across PIM, DAM, MDM and CMS classes in one view.
Keep the channels, shops and ERP in step with the Pimcore master.
Use the structured class history to enrich, tag and classify faster.
Small tools on top of Pimcore for people who should not need platform access.
A list of concrete reports, automations and AI features we have built on Pimcore data. Pick the one that matches your situation.
Is our product, asset and customer data ready to go live on every channel?
Completeness is calculated per custom class, per channel and per locale against the required attribute set defined in Pimcore. The report shows which products, assets or customer records are blocking a channel or campaign, broken down by the class and attribute group responsible.
Which Pimcore assets are still wired into the live storefront, and which are orphaned?
DAM file references are joined with the live commerce catalog, the CMS pages and the product classes that point at them. Orphaned 3D models, unused hero images and videos no page links to show up as a cleanup list, and assets still in use on pages that nobody has updated in six months show up on the same report.
How much drift is there between our Pimcore master and the systems around it?
Pimcore product, customer and vendor masters are joined with the ERP item and supplier tables and with Shopify or Magento product data. Name, price, attribute and identifier differences are flagged per object, so the reconciliation work sits on a queue instead of surfacing when a customer complains.
Master-data quality is a working-capital and compliance story. Vendor records that do not match the ERP, products that cannot launch because an attribute is missing, and customers that exist twice distort margin analysis and tax filings. Pimcore completeness and reconciliation move into the same monthly review as AR and inventory.
Account managers and merchandisers see which product lines, catalogs and assets are ready for which region, channel and customer tier. The weekly planning conversation moves from a Pimcore admin list to a dashboard that also knows what Shopify, Magento and the ad feed are showing.
Product owners, DAM managers and MDM stewards get one view of drift across Pimcore, the ERP and each downstream channel. Workflow stalls, orphaned assets and duplicate masters are worked off a single queue instead of three.
Pimcore products, variants and DAM assets flow into Shopify with locale copy, channel attributes and image references in place. When a product owner fixes a spec or swaps a hero image in Pimcore, the change reaches Shopify without a nightly CSV job, and the warehouse records which version of the product each region saw and when.
Products, categories, attributes and media from Pimcore land in Magento, with configurable-product structures mapped to the Pimcore product class and variant axes. Drift between Magento and the Pimcore master shows up as a warehouse report instead of a customer noticing a wrong price or a broken image on a product page.
Pimcore product classes, category mapping and DAM images drive the Google Merchant feed directly, with GTIN, brand, availability, localised titles and primary images built from the platform. Feed rejections in Merchant Center trace back to the exact Pimcore class or asset that caused them, so the fix lives with the product or DAM team, not the ads team.
Pimcore customer, vendor and item masters are reconciled with Business Central records through the warehouse. New Pimcore objects create the right BC record on the right dimension, and reference changes in BC come back to the Pimcore master, so the ERP and the MDM do not drift apart over the year.
You keep the reporting tool you already have. We connect it to the warehouse where your Pimcore data lives.
OAuth authentication. Read-only by default. We sign a DPA and your admin keeps the keys.
Data flows into your warehouse on your schedule. Near real time or nightly, your call. You own the data.
We build the first dashboard, workflow or AI feature with you, then hand over the keys. Or we stay on for ongoing delivery.
We set up the foundation. Your team builds on top.
Best fit Teams that already have a BI analyst or data engineer and want to own the build.
We build the whole thing, end to end.
Best fit Teams without in-house BI or dev capacity. You tell us what you need and we deliver it.
You do. It lands in your warehouse, on your cloud account. We don't resell or aggregate it. If you stop working with us, the warehouse stays yours and keeps running.
Near real time for most operational systems. For heavier sources we schedule hourly or nightly. You pick based on what the reports need.
No. If you don't have one, we help you pick one and set it up as part of the first delivery. Common starting points are Snowflake, Microsoft Fabric, or a small Postgres start.
Every Pimcore tenant defines its own classes, attributes and data objects through the platform's modeller, so there is no fixed catalog of tables to pull. The connector reads the Pimcore class definitions first and generates a warehouse schema that mirrors the tenant's own classes: products, customers, vendors, assets, CMS documents or whatever else has been modelled. That means the schema is tenant-specific by design, which is the point of Pimcore.
Pimcore exposes both a REST API and a GraphQL Webservices API for data objects and assets. The connector uses whichever the tenant has enabled, with GraphQL preferred on recent versions because it returns the class structure and the data in one call. Incremental pulls use the modification timestamp on data objects and assets.
Both. Pimcore moved the core from GPL to the proprietary POCL license with version 12 in January 2025, and the community picked up the last GPL tree as OpenDXP. The API surface the connector reads is stable across the POCL releases and the OpenDXP fork, so the same warehouse schema works whether you stay on a current Pimcore license, an older GPL version, or the community edition.
We review your Pimcore setup and the systems around it. Together we pick the first thing worth building.