Wer 2026 einen Shopware-6-Shop mit mehr als 5.000 SKUs betreibt, hat den Standard-Export genau einmal benutzt. Danach nie wieder. Nicht, weil das Feature kaputt wäre — sondern weil die nativen CSV-Exporte bei realistischen Datenmengen regelmäßig in Timeouts laufen, keine inkrementellen Updates kennen und bei variantenreichen Produkten jedes einzelne Kindprodukt als eigene Zeile ausspucken, ohne saubere Parent-Child-Hierarchie. Das ist kein Bug. Es ist Design.
Shopware positioniert den Built-in-Export seit Version 6.4 bewusst als Werkzeug für Ad-hoc-Aufgaben: eine schnelle Kundenliste für die Steuerkanzlei, ein Produkt-Dump für den Backup-Ordner, ein Bestellreport für den Controller. Sobald es um kontinuierliche Datenflüsse geht — Marktplatz-Sync mit OTTO, Amazon oder Kaufland, PIM-Anbindung, BI-Tool-Fütterung — kollabiert der native Ansatz.
Was der Standard-Export in Shopware 6 tatsächlich leistet
Der native Export sitzt im Admin unter Einstellungen → Import/Export und deckt vier Datenprofile ab: Produkte, Kategorien, Kunden, Bestellungen sowie eine freie SQL-Abfrage. Jedes Profil lässt sich konfigurieren, als wiederverwendbares Template speichern und über die Administration oder per CLI-Befehl bin/console import-export:run triggern. Für den gelegentlichen Datenzugriff ist das solide gebaut.
Die Grenzen zeigen sich jedoch schnell. Drei Punkte fallen in der Praxis am härtesten aus:
- Exporte laufen synchron im PHP-Prozess. Bei über 20.000 Datensätzen greift in der Regel das
max_execution_time-Limit, der Job bricht ab, der Rest landet im Nirwana. - Es gibt keine inkrementelle Logik. Jeder Lauf exportiert den vollständigen Bestand — auch wenn sich seit dem letzten Mal nur drei Preise geändert haben.
- Variantenprodukte erscheinen als flache Zeilen ohne verlässliche Parent-Referenz. Wer das Ergebnis in Amazon oder ein PIM einspielt, rät die Produktfamilien manuell zusammen.
Warum verlieren Händler bei Marktplatz-Integrationen mit dem Standard-Export Zeit?
Weil Marktplätze Kategorien, Attributsätze und Variantenbeziehungen erwarten, die die Standard-CSV schlicht nicht liefert. Amazon verlangt für jede Variante eine parent_sku plus relationship_type. OTTO arbeitet mit eigenen Merkmalsschablonen, die über die Shopware-Standardfelder hinausgehen. Kaufland führt ein eigenes Kategorie-Mapping mit Pflichtattributen wie Grundpreis-Basis und Energieeffizienzklasse.
In der Praxis heißt das: Der Datenbank-Export aus Shopware ist Rohmaterial. Der eigentliche Wert entsteht im Transformationsschritt — und der gehört nicht in eine Excel-Nachbearbeitung, sondern in eine Middleware wie den Shopware-eigenen Data-Flow von Pickware, in n8n, Make oder einen eigenen API-Service. Das Bundesamt für Wirtschaft und Ausfuhrkontrolle nennt in seiner E-Commerce-Studie 2024 für den deutschen Markt über 480 aktive Marktplätze und Plattformen — kein Händler bedient davon mehr als eine Handvoll mit demselben CSV-Format.
Der Export ist nicht das Problem. Die Illusion, ein generischer CSV-Dump sei ein Integrationsformat, ist das Problem.
Wie funktioniert der Export über die Shopware-6-Admin-API in der Praxis?
Sauberer wird es, wenn man die Admin-API nutzt und auf Pagination plus inkrementelle Filter setzt. Die API liefert für jedes Entity-Endpoint — /api/product, /api/order, /api/customer — konsistente JSON-Strukturen inklusive Assoziationen. Ein einziger GET-Request mit associations auf children, options und media holt eine vollständige Produktfamilie in einem Rutsch. Für Änderungs-Syncs filtert man über updatedAt mit einem Zeitstempel des letzten erfolgreichen Laufs.
Für kleinere Läufe genügt ein Cronjob mit einem simplen Python- oder Node-Skript, das gegen die API paginiert (Standard-Limit 25, maximal 500 pro Request) und die Ergebnisse in ein beliebiges Zielformat schreibt. Für größere Setups mit mehreren hunderttausend Datensätzen und mehreren Zielsystemen lohnt der Weg über Shopware Flow Builder oder eine dedizierte ETL-Pipeline. Der Unterschied ist nicht Performance — der Unterschied ist Wartbarkeit.
Welche Rolle spielen Profil-Exporte für Backup, Reporting und Datenanalyse?
Die meisten Händler brauchen gar keinen vollständigen Export. Sie brauchen drei spezifische Profile: einen täglichen Bestandsabgleich mit dem ERP, einen stündlichen Preis-Feed für Google Shopping, einen wöchentlichen Bestellreport für die Buchhaltung. Das sind drei Jobs mit drei Schemata — nicht ein monolithischer Dump.
Die Shopware-Community hat für genau diese Aufgabe die Erweiterung Import/Export Advanced (ehemals von der Agentur Moorleiche gepflegt) etabliert, die asynchrone Exporte über Queue-Worker fährt, eigene Profile mit Feldauswahl erlaubt und Varianten hierarchisch ausgeben kann. Im Shopware Store kostenpflichtige Alternativen wie die Export-Plugins von Pixup oder NetInventors setzen denselben Hebel an: den synchronen Export umgehen, Profile definieren, inkrementell arbeiten.
Der ehrlichste Blick auf Shopware-6-Exporte: Native Lösung für Ad-hoc-Fragen reicht. Sobald Daten täglich fließen sollen, wird sie zum Hemmschuh. Entscheidend ist die Frage nach der Datenrichtung — zieht ein System (Pull-API) oder schiebt der Shop aktiv (Push via Queue oder Webhook)? Wer Pull nutzt, hat den robusteren Weg, weil Zielanwendungen selbst entscheiden, wann und was sie holen.
Worauf sollten DACH-Händler 2026 konkret achten?
Drei Punkte, die in Projekten immer wieder Geld kosten. Erstens: DSGVO-Compliance beim Kundendatenexport. Ein Kundenexport über die Admin-API enthält personenbezogene Daten. Die Standard-Exporte liefern sie als unverschlüsselte CSV in ein Download-Verzeichnis — bei Auftragsverarbeitung durch Dritte ist das ein erklärungsbedürftiger Zustand. Besser: Exporte verschlüsseln, Zugriff protokollieren oder Auskunftsersuchen direkt über die Shopware-Datenschutz-Funktion abwickeln.
Zweitens: Steuerrelevante Bestelldaten müssen sieben Jahre aufbewahrt werden. Ein automatischer Backup-Export in ein revisionssicheres Ziel (etwa ein S3-Bucket mit Object Lock in einem EU-Rechenzentrum) ist 2026 günstige Versicherung gegen den nächsten Datenvorfall.
Drittens: Wer jetzt eine Marktplatz-Anbindung neu aufsetzt, sollte die Wahl der Middleware von der Datenrichtung abhängig machen. Pull-basierte Feeds (Google, Idealo, Shopping24) brauchen keine Infrastruktur — ein Cron plus API-Client reicht. Push-basierte Anbindungen (Amazon, OTTO, Kaufland, Zalando) brauchen Queues, Retry-Logik und Monitoring. Der Shopware-6-eigene Message Queue auf Basis von RabbitMQ oder Symfony Messenger ist dafür eine unterschätzte Option gegenüber proprietären SaaS-Anbindungen, weil sie im Shop-Stack bleibt und keine zusätzliche Vendor-Lock-in-Fläche aufmacht.
Der Weg von der ersten Test-CSV bis zum stabilen Datenfluss ist keine Tool-Frage. Er ist eine Architektur-Frage — und die entscheidet sich lange vor dem ersten Export-Klick.