Von 10 auf 1000 Bestellungen im Monat: So skalieren Sie Ihren PrestaShop-Shop

Zehn Bestellungen im Monat sind ein Hobby. Hundert sind ein Nebengeschäft. Tausend sind ein echtes Unternehmen. Die Falle liegt darin, den Weg dazwischen für eine sanfte Rampe zu halten. Das ist er nicht. Wachstum in PrestaShop kommt in Stufen, und auf jeder Stufe funktioniert etwas, das gestern noch problemlos lief, plötzlich nicht mehr richtig: Der Shared Host, der 30 Bestellungen locker verarbeitet hat, bricht bei 300 ein; die manuellen Statusänderungen, die zehn Minuten dauerten, fressen jetzt den ganzen Vormittag; die Tabelle ps_cart, die früher kaum ins Gewicht fiel, wird zur langsamsten Abfrage der Website. Dieser Leitfaden zeigt, was bei welchen Bestellmengen in PrestaShop konkret kaputtgeht und was Sie im Back Office ändern sollten, bevor es passiert, nicht erst danach.

Zuletzt aktualisiert: Juni 2026.

Vorab ein Wort zum Umfang. Dies ist der Artikel über die Mechanik der Skalierung: Infrastruktur, Back-Office-Abläufe und Datenbankhygiene bei steigendem Bestellvolumen. Die früheren Phasen behandelt er bewusst nicht noch einmal. Wenn Sie noch um die ersten Bestellungen kämpfen, deckt Ihre ersten 100 Bestellungen: Worauf Sie in der Anfangszeit achten sollten dieses Thema ab; die schonungslos ehrliche Liste der Überraschungen finden Sie in 15 Dinge, die Ihnen vor dem Start niemand sagt. Hier gehen wir davon aus, dass Bestellungen eingehen, und stellen die Frage, ob Ihr Shop sie tragen kann.

Warum PrestaShop-Shops in Stufen brechen, nicht allmählich

Ein PrestaShop-Shop verbraucht beim Wachstum drei Ressourcen, und sie werden nicht gleichmäßig aufgebraucht. Serverkapazität (CPU, RAM, PHP-FPM-Worker, MySQL-Verbindungen) verschlechtert sich unter Gleichzeitigkeit: Alles läuft gut, bis ein Traffic-Schub die Kapazität sättigt, dann ist plötzlich alles gleichzeitig langsam. Ihre eigene Zeit wird linear mit der Bestellzahl aufgezehrt, bis eine einzige manuelle Aufgabe die Grenze von "lästig" zu "ich komme zu nichts anderem mehr" überschreitet. Und die Datenbank wächst monoton mit jedem Warenkorb, Gast, Verbindungs- und Log-Eintrag. Sie schrumpft nicht von selbst, also erreicht sie an einem ganz normalen Dienstag ohne sichtbaren Anlass eine Performance-Klippe.

Weil diese drei Ressourcen an unterschiedlichen Punkten an ihre Grenzen stoßen, erleben Sie Wachstum eher als eine Reihe klarer "alles brennt"-Momente denn als sanften Abfall. Die folgenden Stufen sind danach geordnet, wann welche Begrenzung typischerweise zuschlägt. Verstehen Sie die Bestellzahlen als grobe Marker, nicht als Versprechen: Ein Shop, der pro Woche eine Maschine für 4.000 € verkauft, belastet PrestaShop völlig anders als einer, der 40 Aufkleber für 5 € pro Stunde verkauft.

Die vier Stufen im Überblick

Stufe 1: 1–50 Bestellungen im Monat — widerstehen Sie dem Skalierungsdrang

Bei diesem Volumen ist Ihr Shop nicht der Engpass; die Nachfrage ist es. Ein standardmäßiges PrestaShop auf einem bescheidenen Host verarbeitet 50 Bestellungen im Monat, ohne es zu merken. Der teuerste Fehler in dieser Phase ist verfrühte Infrastruktur: ein dedizierter Server, zusätzliche Caching-Schichten und automatisierte Workflows für Traffic, den Sie noch gar nicht haben. Sie geben Geld aus und, schlimmer noch, Aufmerksamkeit für Probleme, vor denen Sie noch nicht stehen.

Der wirklich sinnvolle technische Schritt in dieser Stufe ist, PrestaShops eigene Produktionshygiene einzuschalten, damit der Shop vom ersten Tag an schnell und sauber läuft. Das kostet nichts. Stellen Sie unter Erweiterte Einstellungen → Leistung den Debug-Modus aus, den Smarty-Cache ein, Kompilierung erzwingen aus, und aktivieren Sie Kombinieren, komprimieren und zwischenspeichern (CCC) für CSS/JS. Das ist in dieser Phase die komplette Infrastruktur-To-do-Liste. Alles andere ist kommerziell: Produkte validieren, Kunden finden. Das ist ein anderes Thema: wie Sie Produkte validieren, bevor Sie investieren und warum Spezialisierung besser ist, als alles verkaufen zu wollen.

Stufe 2: 50–200 Bestellungen im Monat — wenn manuelle Bestellbearbeitung Sie Zeit kostet

Hier spüren die meisten Shopbetreiber zum ersten Mal echten Druck, und der Auslöser ist fast immer derselbe: Bestellstatusverwaltung von Hand. Jede Bestellung in PrestaShop durchläuft Status (Zahlung akzeptiert → Wird bearbeitet → Versendet → Geliefert), und bei 50 Bestellungen pro Tag bedeutet das hunderte Dropdown-Klicks pro Woche unter Bestellungen → Bestellungen. Jeder einzelne davon ist eine Chance, eine Tracking-E-Mail zu vergessen oder etwas zweimal zu versenden.

Automatisieren Sie den Bestelllebenszyklus, nicht nur Benachrichtigungen

PrestaShop löst bei jeder Statusänderung Hooks aus (actionOrderStatusUpdate, actionOrderStatusPostUpdate), und genau dort gehört regelbasierte Automatisierung hin. Statt selbst zu klicken, definieren Sie die Übergänge einmal: Wenn ein Zahlungsmodul bestätigt, automatisch auf In Bearbeitung setzen; wenn eine Sendungsnummer gespeichert wird, automatisch auf Versendet setzen und die Kundenbenachrichtigung auslösen. Genau dafür ist unser Modul Advanced Order Workflow gedacht — was bringt Ihnen das konkret? Die Stunde pro Tag, die Sie derzeit mit der Pflege der Bestellliste verbringen, bekommen Sie zurück, mit weniger menschlichen Fehlern und konfigurierbar im Back Office, ohne Code anzufassen. Der Gewinn in dieser Stufe ist kein schnellerer Server; es ist zurückgewonnene eigene Zeit, die nicht linear mit der Bestellzahl wächst.

Bringen Sie das Hosting maßvoll in Vorleistung

Wenn Sie noch auf Shared Hosting laufen, ist dies die Stufe für den Wechsel auf einen VPS: 4 GB RAM, SSD und PHP 8.1+ sind eine vernünftige Untergrenze. Der Grund ist Gleichzeitigkeit, nicht die reine Bestellzahl. Hunderte tägliche Sessions bedeuten viele gleichzeitige PHP-Prozesse und MySQL-Verbindungen, und Shared Hosting entzieht Ihnen beides unter Last. Sie brauchen noch keinen dedizierten Server; Sie brauchen vorhersehbare Ressourcen, die Sie nicht mit einem lauten Nachbarn teilen.

Stufe 3: 200–500 Bestellungen im Monat — Genauigkeit und Geschwindigkeit werden zum Problem

Jetzt führen Sie ein echtes Geschäft, und die Fehlermuster ändern sich von "das ist mühsam" zu "das ist falsch" und "das ist langsam". Drei Dinge schlagen meist gleichzeitig zu.

Lagerbestandsabweichungen

Tabellenkalkulationen für den Warenbestand funktionieren, bis sie es nicht mehr tun. Bei 200+ Bestellungen im Monat, dazu Retouren, manuelle Anpassungen und vielleicht ein zweiter Verkaufskanal, laufen Ihr erfasster Bestand und Ihr echter Bestand auseinander, und Sie beginnen, zu viel zu verkaufen. Der native Lagerbestand von PrestaShop liegt in ps_stock_available und reicht für die Zählung in einem einzelnen Lager aus. Er hat sogar Warnungen für niedrige Bestände. Aber er bietet keinen Bestellworkflow für Einkauf, keine fortgeschrittene Nachschubplanung und kein echtes Multi-Location-Modell. Wenn Sie sich dieser Grenze nähern, ergänzt unser Modul Warehouse Revolution lagerbezogene Bestände, Warnungen bei niedrigem Bestand und Nachbestellmanagement, damit die Zahl im Back Office zur Zahl im Regal passt. (Die größere Frage "was betreibe ich selbst und was gebe ich ab" — Fulfillment, Support, Buchhaltung — ist eine eigene Entscheidung: siehe was Sie delegieren sollten und was im Haus bleiben sollte.)

Supportvolumen jenseits eines Posteingangs

Sie können nicht mehr jede Nachricht ad hoc aus Ihrem persönlichen Posteingang beantworten. Der integrierte Kundenservice von PrestaShop (Kundenservice → Kundenservice) fasst Kontaktformular-Nachrichten in Threads zusammen, und die Weiterleitung nach Thema — Bestellungen, Retouren, Vorverkauf — hält die Antwortzeiten bei steigendem Volumen im Rahmen. Ein kategorisiertes, sauber geroutetes Kontaktformular wie unser Better Contact Form speist diesen Workflow ordentlich. Dies ist auch die Stufe, in der die Frage "soll ich jemanden einstellen?" zum ersten Mal real wird. Die tatsächlichen Signale haben wir in wann Sie Ihren ersten Mitarbeiter einstellen sollten durchgearbeitet, und warum schnelle Antworten kommerziell zählen, in warum wir jedes Ticket innerhalb weniger Stunden beantworten.

Seitengeschwindigkeit wird zum Umsatzhebel

Bei tausenden Seitenaufrufen pro Tag ist Time-to-First-Byte keine Eitelkeitsmetrik mehr. PrestaShops standardmäßiges Rendering pro Anfrage bedeutet, dass jeder nicht gecachte Seitenaufruf PHP und einen Stapel SQL ausführt. Zwei Schritte zählen hier. Erstens: Verschieben Sie PrestaShops Query-Cache in einen In-Memory-Store wie Redis, damit wiederholte Lesezugriffe MySQL nicht belasten. PrestaShops Bildschirm Erweiterte Einstellungen → Leistung → Caching bietet nativ Memcached/APCu; speziell für Redis verbindet unser Modul Instant Redis alles ohne Arbeit an der Serverkonsole. Zweitens: Stellen Sie statische Assets vor ein CDN, damit Bilder und CCC-Bundles nicht alle vom Origin kommen. Die detaillierte Analyse zur Diagnose von PrestaShop-Langsamkeit ist ein eigener Beitrag — verlinken Sie ihn lieber, statt ihn hier hastig abzuhandeln — aber das Prinzip in dieser Stufe lautet: weniger Datenbank-Roundtrips pro Besucher.

Stufe 4: 500–1000+ Bestellungen im Monat — Infrastruktur und Gleichzeitigkeit

Jenseits von 500 Bestellungen haben Sie typischerweise tausende tägliche Besucher im Katalog, während gleichzeitig ein stetiger Strom von Käufern die Kasse nutzt, und die Datenbank wird zur umkämpften Ressource. In dieser Stufe hören Sie auf zu tunen und beginnen zu architektieren.

Full-Page-Caching ist nicht mehr optional

Die Veränderung mit dem größten Hebel ist hier, den größten Teil des Katalog-Traffics aus dem Cache zu bedienen, statt ihn jedes Mal neu zu generieren. CCC (Stufe 1) minimiert nur Assets; es verhindert nicht, dass PHP und MySQL die Seite neu aufbauen. Full-Page-Caching liefert anonymen Besuchern eine gespeicherte HTML-Kopie, sodass Ihre PHP-Worker und die Datenbank für die Personen reserviert bleiben, die tatsächlich in den Warenkorb legen und zur Kasse gehen. Unser Modul Performance Revolution liefert das auf Anwendungsebene, oder eine Varnish-Schicht vor Nginx/Apache erledigt es am Rand. Übersetzt ins Geschäft: Derselbe Server fängt jetzt einen Traffic-Spike ab, der den Shop früher mitten in einer Promotion lahmgelegt hätte — und eine Kasse, die während Ihrer besten Verkaufsstunde erreichbar bleibt, ist der ganze Punkt.

Trennen Sie die Datenbank vom Webserver

Auf einer einzelnen Maschine kämpfen MySQL und PHP-FPM unter Last um denselben RAM und dieselbe CPU. Wenn Sie MySQL auf einen eigenen Host verschieben — PrestaShop liest seine DB-Verbindung aus app/config/parameters.php (oder config/settings.inc.php in 1.6), es ist also eine Konfigurationsänderung, keine Codeänderung — kann sich jede Maschine spezialisieren: Web-Knoten führen PHP aus, der DB-Knoten verarbeitet Abfragen mit reichlich Buffer-Pool-RAM (16 GB+ sind in dieser Größenordnung vernünftig). Wenn Sie bei einem einzelnen Server bleiben, sind NVMe-Speicher und 8 GB+ RAM die praktische Untergrenze.

Alles wird zur Massenoperation

Admin-Arbeit einzeln pro Bestellung, die in Stufe 2 noch erträglich war, ist jetzt ein Vollzeitjob, den niemand haben sollte. Sie müssen 50 Lieferscheine mit einer Aktion drucken, 100 Bestellstatus mit einer Auswahl ändern und Bestellungen für Ihren Buchhalter oder 3PL in eine einzige Datei exportieren, statt Daten zu kopieren und einzufügen. PrestaShops Bestellliste unterstützt Massenaktionen nativ; für saubere, gefilterte Exporte wandelt unser Orders CSV List Exporter eine gefilterte Bestellansicht in eine fertige CSV um. Die Regel in dieser Stufe: Wenn eine Aufgabe mit der Bestellzahl skaliert und Sie sie pro Bestellung erledigen, ist sie ein Leck.

Sicherheit und Zugriffskontrolle bei höherem Einsatz

Mehr Volumen bedeutet mehr Geldfluss und ein größeres Ziel. Zwei PrestaShop-native Schritte zuerst: Erstellen Sie echte Mitarbeiterprofile unter Erweiterte Einstellungen → Team mit Berechtigungen passend zur Aufgabe (Ihr Packer braucht nicht die Tabs Zahlung oder Kunden), und aktivieren Sie die Katalog-/Log-Überwachung, die Brute-Force- und Scan-Aktivitäten erkennt — unser Modul Security Revolution deckt die Monitoring-Seite ab. Backups sind dann nicht mehr nur eine gute Idee, sondern nicht verhandelbar: Bei 1.000 Bestellungen im Monat ist ein verlorener Datenbanktag ein verlorener Umsatz- und Kundendatentag.

Die Datenbank ist der Teil, den niemand beobachtet, bis es zu spät ist

Das verdient einen eigenen Abschnitt, weil es der häufigste stille Killer eines wachsenden PrestaShop-Shops ist. Jeder Besucher, der nicht kauft, hinterlässt trotzdem Zeilen: einen abgebrochenen Warenkorb in ps_cart, einen Gast in ps_guest, eine Verbindung in ps_connections / ps_connections_source, Seitenaufrufe in ps_page_viewed und Statistiken in den Tabellen ps_stats* (ps_statssearch, ps_statsdata und ähnliche). Ein Shop mit 1.000 Bestellungen hat vielleicht 50.000+ Sessions, von denen die überwältigende Mehrheit nur diese Tabellen aufbläht. Sich selbst überlassen wachsen sie unbegrenzt, bis Joins dagegen das gesamte Back Office verlangsamen und Warenkorbregel-Prüfungen an der Kasse zu ziehen beginnen.

Die Lösung ist eine geplante Bereinigung abgelaufener Warenkörbe, verwendeter/abgelaufener Warenkorbregeln und alter Statistikzeilen — sorgfältig, weil einige dieser Tabellen legitime Auswertungen speisen. Unser Modul Cleanup Revolution automatisiert diese Wartung nach Zeitplan, damit die Datenbank bei steigendem Volumen schlank bleibt, statt dass Sie daran denken müssen, SQL von Hand auszuführen (und riskieren, das Falsche zu löschen). Und was bringt das? Ein Back Office, das bei 1.000 Bestellungen genauso reaktionsschnell bleibt wie bei 100, ohne rätselhafte Verlangsamung in drei Monaten.

Die Fehler, die in jeder Stufe auftauchen

• Zu früh skalieren. Stufe-4-Infrastruktur bei 30 Bestellungen im Monat kaufen. Sie geben Geld und Aufmerksamkeit für Probleme aus, die Sie nicht haben, und vernachlässigen dabei das eine Problem, das Sie tatsächlich haben: Nachfrage.
• Zu spät skalieren. Warten, bis die Website während einer Promotion zusammenbricht, bevor Sie Full-Page-Caching einführen. Wenn Kunden Ihnen sagen, dass sie langsam ist, haben Sie die Bestellungen bereits verloren.
• Tools hinzufügen, statt Reibung zu entfernen. Zehn halb konfigurierte Module auf eine langsame Basis stapeln. Weniger Module, richtig genutzt, schlagen mehr Module, schlecht genutzt. Zusätzliche Module bedeuten zusätzliche Hooks, die bei jedem Seitenaufruf laufen.
• Die Datenbank ignorieren. Oben behandelt: die Klippe, die Sie nicht kommen sehen.
• Kein Monitoring. In dieser Größenordnung müssen Sie von einem Ausfall durch einen Alarm erfahren, nicht durch eine Kunden-E-Mail. Uptime-Checks und Fehlertracking sind eine günstige Versicherung gegen einen teuren stillen Ausfall.

Das Prinzip: einen Schritt voraus, nicht zehn

Der Shop, der 1.000 Bestellungen verarbeitet, teilt fast keine Infrastruktur mit dem Shop, der 10 Bestellungen verarbeitet hat, und genau so sollte es sein. Der falsche Zug ist, am ersten Tag das 1.000-Bestellungen-Setup bauen zu wollen; der andere falsche Zug ist, Upgrades zu verweigern, bis etwas bricht. Das Muster, das funktioniert: ungefähr eine Stufe vor Ihrem tatsächlichen Volumen bleiben. Bei 200 Bestellungen bereiten Sie leise 500 vor, damit die Systeme bereits stehen, wenn Sie 500 erreichen, und Wachstum sich wie Schwung anfühlt statt wie Krise.

Und die Wirtschaftlichkeit zählt genauso wie die Technik. Bestellvolumen zu skalieren lohnt sich nur, wenn jede zusätzliche Bestellung tatsächlich profitabel ist, sobald Sie die echten Kosten mitzählen: Zahlungsgebühren, Supportzeit, Retouren, die oben beschriebene Infrastruktur. Bevor Sie das Volumen stark antreiben, stellen Sie sicher, dass die Stückökonomie trägt: Ihre echten Gewinnmargen verstehen und die Kosten, über die niemand spricht. Tausend profitable Bestellungen sind ein echtes Unternehmen; tausend Bestellungen ohne Gewinn sind nur tausend Arbeitseinheiten.

FAQ

Die Bestellzahlen passen nicht zu meinem Shop — verstehe ich die Stufen falsch?

Nein. Verstehen Sie die Bestellzahlen als grobe Marker, nicht als Schwellenwerte. Entscheidend ist der begrenzende Faktor, nicht die Zahl. Ein Shop, der eine Handvoll hochwertiger Maschinen verkauft, stößt viel später an Datenbank- und Gleichzeitigkeitsschranken als einer, der viele günstige Artikel verkauft, weil der zweite pro Bestellung viel mehr Sessions, Warenkörbe und Katalogseitenaufrufe erzeugt. Finden Sie Ihre Stufe danach, welches Symptom zuerst beißt: manuelle Workflows, die Ihren Tag auffressen, Lagerbestandsabweichungen, langsame Seiten oder eine Kasse, die unter Last zusammenbricht. Handeln Sie danach, nicht nach einer Ziel-Bestellzahl.

Wann sollte ich Full-Page-Caching hinzufügen — ab wann reicht CCC nicht mehr?

Fügen Sie Full-Page-Caching hinzu, wenn anonymer Katalog-Traffic Seiten neu generiert, mit denen Ihre PHP-Worker und die Datenbank bei einem Spike nicht mehr mithalten können. Das ist meist etwa in der Stufe von 500 Bestellungen im Monat der Fall, wenn Sie tausende tägliche Besucher haben. CCC minimiert und kombiniert nur CSS/JS; es verhindert nicht, dass PHP und MySQL die Seite bei jedem Aufruf neu aufbauen. Full-Page-Caching liefert anonymen Besuchern gespeichertes HTML, sodass Ihre Worker und die DB für Personen reserviert bleiben, die tatsächlich in den Warenkorb legen und zur Kasse gehen. Wenn eine Promotion die Website schon einmal bis zur Unbenutzbarkeit verlangsamt hat, sind Sie bereits über den Punkt hinaus, an dem es hätte aktiv sein sollen.

Muss ich die Datenbank wirklich bereinigen, oder ist das verfrühte Optimierung?

Sobald Sie über ein paar hundert Bestellungen im Monat hinaus sind, wird es echte Wartung, keine verfrühte Optimierung. Jeder nicht kaufende Besucher hinterlässt trotzdem Zeilen: abgebrochene Warenkörbe in ps_cart, Gäste, Verbindungen, Seitenaufrufe, Statistiken. Diese Tabellen wachsen nur. Ein Shop mit 1.000 Bestellungen kann 50.000+ Sessions haben, von denen die große Mehrheit nur diese Tabellen aufbläht, bis Joins dagegen das Back Office ausbremsen und Warenkorbregel-Prüfungen an der Kasse verlangsamen. Geplante Bereinigung abgelaufener Warenkörbe, verwendeter Warenkorbregeln und alter Statistiken hält die Datenbank schlank. Tun Sie es sorgfältig, weil einige dieser Tabellen legitime Reports speisen.

Sollte ich MySQL auf einen eigenen Server verschieben oder einfach eine größere Maschine kaufen?

Bleiben Sie auf einer einzelnen, gut ausgestatteten Maschine (NVMe-Speicher, 8 GB+ RAM), solange ein Server Ihre Spitzenlast komfortabel aufnimmt. Trennen Sie die Datenbank auf einen eigenen Host, sobald MySQL und PHP-FPM unter Last sichtbar um denselben RAM und dieselbe CPU kämpfen. Das passiert typischerweise tief in der Stufe 500–1.000+. PrestaShop liest seine DB-Verbindung aus der Konfiguration (app/config/parameters.php oder config/settings.inc.php in 1.6), das Verschieben der Datenbank ist also eine Konfigurationsänderung, keine Codeänderung. Nach der Trennung spezialisiert sich jede Maschine: Web-Knoten führen PHP aus, der DB-Knoten verarbeitet Abfragen mit großem Buffer Pool.

Was ist der häufigste Skalierungsfehler?

Die zwei entgegengesetzten Fehler, beide gleich teuer. Zu früh skalieren — Stufe-4-Infrastruktur bei 30 Bestellungen im Monat kaufen — verbrennt Geld und Aufmerksamkeit für Probleme, die Sie nicht haben, während Sie das eigentliche Problem vernachlässigen: Nachfrage. Zu spät skalieren — warten, bis die Website mitten in einer Promotion zusammenbricht, bevor Sie Caching hinzufügen — bedeutet, dass Kunden Ihnen erst sagen, dass sie langsam ist, nachdem Sie die Bestellungen bereits verloren haben. Das Muster, das funktioniert: ungefähr eine Stufe vor Ihrem tatsächlichen Volumen bleiben, damit die Systeme kurz vor dem Moment bereitstehen, in dem Sie sie brauchen.