JTL-Wawi hosten: Cloud, eigener Server oder doch der Rechner im Büro?
Warum die SQL-Datenbank fast nie das Problem ist — und die Leitung fast immer.
Die häufigste Frage, die mir Händler beim Erstgespräch stellen, lautet sinngemäß: „Unsere Wawi ist so langsam — brauchen wir einen stärkeren Server?” In neun von zehn Fällen lautet die Antwort: nein. Der Server ist nicht das Problem. Das Problem ist meistens die Kombination aus falsch konfigurierter SQL-Instanz und einer Leitung, über die die Wawi hunderte Male hin- und herfragt.
Deshalb hier einmal sortiert: welche drei Betriebsmodelle es gibt, wann welches passt, und welche Stellschrauben tatsächlich etwas bringen.
Die drei Betriebsmodelle
1. Lokal auf einem Arbeitsplatz-PC. Der Klassiker beim Start: SQL Server Express läuft auf dem Rechner, an dem auch gearbeitet wird. Kostet nichts, funktioniert bis zu einer gewissen Größe erstaunlich gut — und wird genau dann zum Risiko, wenn das Geschäft läuft. Der Rechner wird abends ausgeschaltet, der Worker steht, der Shop-Abgleich läuft nicht mehr. Und SQL Server Express deckelt die Datenbank bei 10 GB. Diese Grenze erreicht man mit Bestellhistorie, Bildern und Logs schneller als gedacht.
2. Eigener Server im Büro. Ein Stück Hardware im Schrank, Windows Server, SQL Server Standard, alle Arbeitsplätze im selben Netz. Technisch die schnellste Variante, weil die Latenz im LAN bei unter einer Millisekunde liegt. Der Preis dafür: Sie betreiben Hardware. Strom, Klima, USV, Windows-Updates, Backups, und bei einem Defekt am Samstagabend sitzen Sie selbst davor.
3. Gehostet im Rechenzentrum. Die Datenbank liegt auf einem dedizierten Server, die Clients verbinden sich über eine abgesicherte Verbindung. Backups, Updates und Monitoring laufen fremdbetreut. Sie zahlen monatlich statt einmalig und tauschen Kontrolle gegen Verfügbarkeit.
Was wirklich über die Geschwindigkeit entscheidet
Hier wird es interessant, denn die Reihenfolge der Faktoren überrascht viele.
Latenz schlägt Rechenleistung
Die JTL-Wawi ist ein sogenannter Fat Client: Sie schickt für einen einzigen Vorgang — Artikel öffnen, Auftrag speichern, Liste filtern — oft mehrere hundert einzelne Abfragen an die Datenbank. Jede dieser Abfragen wartet auf ihre Antwort, bevor die nächste losgeschickt wird.
Rechnen wir das durch: Bei 300 Abfragen und 1 ms Latenz im LAN kommen 0,3 Sekunden reine Wartezeit zusammen. Über eine Internetleitung mit 25 ms Latenz sind es 7,5 Sekunden — bei identischer Serverhardware. Der Server langweilt sich in beiden Fällen.
Das ist die wichtigste Erkenntnis für jede Hosting-Entscheidung: Ein doppelt so schneller Prozessor bringt Ihnen nichts, wenn die Wartezeit auf der Leitung entsteht. Was hilft, ist entweder eine kurze Strecke (LAN) oder ein Arbeiten direkt auf dem Server per Remote-Desktop — dann laufen die Abfragen lokal, und über die Leitung geht nur noch das Bildschirmbild.
Der Speicher-Deckel der SQL-Instanz
Der zweitgrößte Bremsklotz ist ein Feld in den SQL-Server-Einstellungen, das nach der Installation gerne auf einem winzigen Wert stehen bleibt: die maximale Serverspeicherbelegung. Ich habe Instanzen auf einem Server mit 64 GB RAM gesehen, die auf 2 GB gedeckelt waren. Die Folge: Die Datenbank kann den Bestand nicht im Arbeitsspeicher halten und liest permanent von der Platte nach.
Prüfen Sie das im SQL Server Management Studio über die Servereigenschaften unter Arbeitsspeicher. Als Richtwert lassen Sie dem Betriebssystem 4 bis 8 GB und geben den Rest der Instanz — bei mehreren Instanzen entsprechend aufgeteilt.
Zwei weitere Einstellungen, die in der Praxis viel bringen:
- Max Degree of Parallelism (MAXDOP): bei bis zu 8 Kernen auf 4 setzen, statt es auf 0 stehen zu lassen.
- Cost Threshold for Parallelism: von 5 auf etwa 50 anheben. Der Standardwert stammt aus den Neunzigern und sorgt dafür, dass selbst triviale Abfragen parallelisiert werden — mit mehr Verwaltungsaufwand als Nutzen.
Platte: SSD oder NVMe, nichts anderes
Eine JTL-Datenbank auf einer klassischen Festplatte ist kein Betrieb, das ist Warten mit anderen Mitteln. NVMe-SSDs sind seit Jahren Standard und im Servergeschäft kein Preistreiber mehr.
Wann welches Modell passt
| Situation | Empfehlung |
|---|---|
| Ein Arbeitsplatz, unter 10.000 Artikel, kein Shop | Lokal, aber mit externem Backup |
| 2–10 Arbeitsplätze an einem Standort | Eigener Server im LAN |
| Mehrere Standorte oder Homeoffice | Gehostet, Arbeiten per Remote-Desktop |
| Kein eigenes IT-Personal | Gehostet |
| Datenbank über 10 GB | In jedem Fall SQL Server Standard statt Express |
Die Zeile, die am häufigsten unterschätzt wird, ist die vorletzte. Wer keine IT-Abteilung hat, betreibt trotzdem eine — nur eben nebenbei, abends, unter Zeitdruck.
Die Punkte, die beim Hosting-Anbieter zählen
Wenn Sie sich für eine gehostete Lösung entscheiden, sind das aus meiner Sicht die Fragen, bei denen sich die Spreu vom Weizen trennt:
- Eigene Datenbank oder geteilte Instanz? Eine eigene Datenbank auf einer Instanz mit reserviertem Speicher verhält sich völlig anders als eine geteilte Instanz, in der der Nachbar Ihren Cache verdrängt.
- Läuft der JTL-Worker als Dienst? Wenn der Worker nur läuft, solange jemand angemeldet ist, stehen nachts Ihre Shop-Abgleiche und Zahlungsabholungen.
- Wie kommt man an die Datenbank? Ein SQL-Port, der offen im Internet steht, ist ein Sicherheitsproblem. Zugriff gehört auf eine IP-Freigabe oder ein VPN beschränkt.
- Wird das Restore getestet? „Wir machen Backups” ist keine Aussage. Die relevante Frage lautet: Wann wurde zuletzt eine Sicherung tatsächlich zurückgespielt, und wie lange hat das gedauert?
- Was passiert beim Wawi-Update? Ein Wawi-Update braucht auf dem SQL Server bestimmte Rechte, sonst bricht es mit einer wenig hilfreichen Meldung ab. Ein Anbieter, der das kennt, hat das vorbereitet.
Was ich Händlern in der Praxis rate
Wenn Sie an einem Standort mit wenigen Arbeitsplätzen sitzen und jemanden im Haus haben, der sich mit Windows auskennt: bleiben Sie bei eigener Hardware im LAN. Das ist schnell, billig im Betrieb und in Ihrer Hand.
Sobald aber jemand aus dem Homeoffice arbeitet, ein zweiter Standort dazukommt oder niemand Lust hat, sich um Backups zu kümmern, wird gehostetes Hosting mit Remote-Desktop-Zugriff die ruhigere Lösung. Nicht weil der Server im Rechenzentrum stärker wäre — sondern weil Sie damit das Latenzproblem lösen, statt es zu verwalten.
Und in beiden Fällen gilt: Schauen Sie zuerst in die SQL-Einstellungen, bevor Sie neue Hardware kaufen. Ich habe schon Systeme durch das Anheben eines einzigen Speicherwerts von „unbenutzbar” auf „läuft” gebracht.
Häufige Fragen
Kann man JTL-Wawi wirklich in der Cloud betreiben?
Ja. Die Wawi ist ein Windows-Client, der auf eine SQL-Server-Datenbank zugreift. Liegt die Datenbank auf einem gehosteten Server und der Client verbindet sich per VPN oder direkter Freigabe, funktioniert das zuverlässig — vorausgesetzt die Latenz zwischen Arbeitsplatz und Server bleibt niedrig. Bei mehreren Standorten ist eine gehostete Datenbank meist sogar die stabilere Lösung als ein Rechner im Büro.
Wie viel RAM braucht der SQL Server für JTL-Wawi?
Als Faustregel: mindestens 8 GB nur für die SQL-Instanz bei kleinen Beständen, 16 GB und mehr ab etwa 50.000 Artikeln oder aktivem Shop-Abgleich. Entscheidend ist, dass die maximale Serverspeicherbelegung in SQL Server auch tatsächlich hochgesetzt ist — der Standardwert nach einer Installation ist häufig viel zu niedrig eingestellt.
Was kostet gehostetes JTL-Wawi-Hosting im Monat?
Realistisch bewegen sich seriöse Angebote je nach Datenbankgröße, Nutzerzahl und Backup-Umfang im Bereich von etwa 25 bis 100 Euro pro Monat. Deutlich günstigere Angebote sparen fast immer an denselben Stellen: geteilte SQL-Instanz ohne Speicherreservierung, kein getestetes Restore, kein Worker-Dienst.
