Ich kann mir gut vorstellen, dass die 10MB aus der "externen Datenquelle" relativ redundant gehalten sind.
In einem guten Modell hast Du für die Bewegungsdaten fast nur noch Zahlen/ID, damit kommt man vielleicht auf einen deutlich geringeren Wert als die von Dir insgesamt berechneten 730 GB. Bei großen Datenmengen lohnt auch die Überlegung, ob die Zahl als Byte, Word oder Double gespeichert werden muss. Letztlich sollte das Thema aber keinen großen Einfluss auf das gewählte
DB System haben.
Ein Bekannter von mir verwaltet ein vergleichbares System für einen großen Lebensmitteldiscounter- nicht der mit A-
Zentraler Server und lokale alles Oracle
DB.
Für Deine Fragestellung ist m.E. nicht so sehr entscheidend, wieviel Daten das System der Wahl halten kann, sondern jegliche Art von performanter und robuster Datenverarbeitung, die das System bietet.
Das beginnt mit dem Deployment (Datenmodell), geht über täglich/nächtlich/online Datenaustausch, Robustheit, Backupverfahren und Pflege (Datenmodelländerung*)
Oracle verfügt über sehr mächtige Synchronisierungsfunktionen inkl DDL und verteilte Transaktionen und dürfte im Bereich Performance/Robustheit führend sein. Auch im Detail gibt es schon in der Standard Version (seit V8) viele (Analyse-)Funktionen, die die Konkurrenz seit dem nachbaut. OLAP / DWH kann es natürlich auch, ist eigentlich ein extra Thema.
Postgres "kenne" ich erst kurz. Verhält sich etwas störisch bei Installation und Zugriffskonfiguration (oder sagen wir, es bietet sehr viele Möglichkeiten), soll sehr Oracle kompatibel sein, konnte ich aber noch nicht verifizieren.
Zu den anderen System habe ich keine nennenswerte bzw. aktuellen Erfahrungen.
* Datenmodelländerung & Co.
Das System (der zentrale Server) muss die gesamte, tägliche Transaktionslast schlucken, entweder über VPN oder über Standleitungen. Internetverbindungen/VPN sind dabei wahrscheinlich noch Dein Freund. Standleitungen eher nicht, gibt's auch außerhalb DE Standorte?
Wie auch immer, man braucht serverseitig viel Bandbreite und muss ein smartes, fehlertolerantes Replikationsverfahren bauen. Und jetzt zum *: Eine Modelländerung kann in solch einem System ziemlich kniffelig werden. Die Master
DB muss die Änderung kennen/können (z.B. auch inkl. aller Auswertungen), die Modelländerungen müssen zeitnah, planbar auf alle Clienten ausgerollt werden können und fehlerfrei durchlaufen. Die Synchronisation muss danach wieder fehlerfrei weiterlaufen. Alternative wäre- aufwändiger, aber vielleicht unkritischer- ein Verfahren, das mit 2 Modelversionen und schrittweisem Upgrade der Standorte arbeit.
Und der Admin sollte von diesen Dingen auch irgendwie Ahnung haben finde ich.