Zum Inhalt springen

Vierzig Websites in einer Odoo-Instanz

Was sie spart, was geteilt wird und wann die geteilten Worker zum Problem werden.
11. September 2026 durch

Vierzig Onlineshops, vierzig Domains, vierzig Designs - und ein Odoo hinter allen. Das ist kein Trick: Odoo betreibt mehrere Websites von Haus aus. Wovon niemand spricht: wo die Rechnung für diesen Komfort ankommt.

Vierzig Shops teilen sich eine Odoo-Instanz, einen Katalog und einen Worker-Pool
Geteilt wird alles - auch die Worker.

Was eine Instanz einbringt

Ein Katalog, ein Lager, eine Liste von Aufträgen. Ein einmal bearbeitetes Produkt erscheint in jedem Shop, der es verkauft, mit demselben Bestand, den alle anderen sehen. Ein Kunde, der in zwei Shops bestellt hat, ist im System einer und nicht zwei.

Und eine Stelle für den Deploy. Vierzig getrennte Installationen bedeuten vierzig Updates, vierzig Backups, vierzig Zugangsdatensätze und vierzig Rechnungen im Monat. Eine Änderung an der Kasse wird einmal geschrieben und landet überall gleichzeitig.

Was jede Website für sich behält

Domain, Theme, Menüs, Sprachen und Preise gehören der Website, nicht der Instanz. Zwei Shops auf demselben Odoo können äußerlich nichts gemeinsam haben und dasselbe Produkt zu unterschiedlichen Preisen in unterschiedlichen Währungen verkaufen.

Auch Inhalte sind getrennt: Seiten, Beiträge und Produkte hängen an einer Website, und der Besucher eines Shops stolpert nie über die Seiten eines anderen. Die Trennung ist ein Feld am Datensatz - genau deshalb ist sie billig.

Wo es weh tut: die Worker

Alle vierzig Websites teilen sich einen Pool von Odoo-Workern. Ein Worker ist ein Prozess und bedient eine Anfrage nach der anderen. Vierzig Shops bekommen nicht vierzig Mal so viele Prozesse - sie bekommen denselben Pool wie ein einzelner.

Eine schwere Seite in einem Shop ist deshalb nicht dessen Privatproblem. Während ein Worker acht Sekunden mit einer Katalogsuche verbringt, antwortet er den anderen neununddreißig Websites nicht. Multipliziert mit den Leuten, die den ganzen Tag suchen, ist der Pool dauerhaft belegt.

Das war der zweite Grund, die Suche aus der Datenbank zu holen, nicht nur die Größe des Katalogs: die Suche, die acht Sekunden dauerte , band die Worker von vierzig Websites.

Odoo.sh oder eigener Server

Auf Odoo.sh funktionieren mehrere Websites genau so, wie sie sollen, und Skalierung und Backups gibt es ohne Serverarbeit. Was es nicht gibt, ist das Recht, etwas neben Odoo laufen zu lassen: kein eigenes Redis, kein eigener Dienst. Alles Zusätzliche lebt außerhalb und antwortet über das Netz.

Auf einem eigenen Server mit Enterprise stehen die zusätzlichen Dienste im selben Subnetz wie Odoo. Weniger Sprünge, geringere Latenz und volle Kontrolle darüber, was dort läuft - im Tausch gegen die Pflicht, es selbst zu betreiben.

Wann eine Instanz die falsche Antwort ist

Wenn die Geschäfte wirklich nichts miteinander zu tun haben: andere Firmen, andere Buchhaltung, Leute, die fremde Aufträge nicht sehen dürfen. Odoo trennt auch das, aber die Konfiguration wird schwer, und ein Fehler in einer Zugriffsregel ist dann kein Bug mehr, sondern ein Leck zwischen Geschäften.

Und wenn einer der Shops so viel größer ist als die übrigen, dass er in einem gemeinsamen Pool nichts verloren hat. Dann zieht er aus. Die Regel ist einfach: eine Instanz, solange die Websites Daten und Leute teilen, getrennte Instanzen, wenn sie nur noch den Eigentümer teilen.

Und wenn die Instanz noch nicht feststeht, fangen Sie einen Schritt früher an - beim Preis von Odoo, Salesforce, HubSpot und SAP für zehn Personen.

Wie verhalten sich dieselben Systeme im Alltag? Odoo Erfahrungen aus dem Produktivbetrieb: was trägt, was bricht.

Die Suche über 110.000 Produkte dauerte acht Sekunden. Jetzt eine.
Warum die Lösung kein größerer Server war und was der Betrieb danach kostet.