Auch in zeitkritischen Systemen fallen diverse Daten an, welche gespeichert und später wieder abgerufen werden sollen – ein Datenbanksystem bietet sich an. In einigen Fällen kann es erforderlich sein, die Daten noch im laufenden Prozess in einem vorgegebenen Zeitfenster zu aggregieren oder wieder auszulesen, um so einen reibungslosen Ablauf des Prozesses zu garantieren.

In solch einem Fall wird eine neue Anforderung an das Datenbank-System gestellt: Es muss die Daten in Echtzeit annehmen, verarbeiten und wieder ausgeben können. Eine besondere Problematik ergibt sich, wenn der Prozess nicht nur weiche, sondern sogar harte Echtzeit fordert:

Es muss immer für den Worst Case geplant werden: Theoretisch könnten alle denkbaren Datenbank-Anfragen gleichzeitig hereinkommen, müssen aber dennoch innerhalb der jeweils festgelegten Deadline fertig werden. Mögliche Ansätze in diesem Fall sind z.B.:

• Alle DB-Anfragen vorher inklusive der max. betroffenen Datenmengen
  planen nur die Daten-Inhalte sind flexibel, vgl. Prepared Statements
• weitere Regeln (Constraints) einführen, die Eigenschaften von Daten beschreiben
  z.B.: in Tabelle X sind höchstens 21 verschiedene Werte in der Spalte "Datenbus"
• hohe Parallelisierung der Anfragen
  Konfliktlösung bei schreibenden Anfragen nötig

Ein Problem bleibt jedoch: Für harte Echtzeit muss nach wie vor die Hardware/Rechenleistung für den Worst Case bereitgestellt werden, der jedoch meist nur selten eintritt. Da sich diese Problematik prinzipbedingt auch nicht umgehen lässt, scheint es lohnenswert, einen anderen Weg zu gehen:

So könnten nicht-zeitkritische Anfragen oder Anfragen mit weicher Echtzeit in den „Pausen“ bzw. in Zeiten geringer Auslastung behandelt werden. Wichtig ist dabei, dass die Hardware sobald nötig in harter Echtzeit wieder für Echtzeitanfragen bereitsteht.