A real-time database, in some ways, is similar to a traditional database. Both are meant to hold data, and both need to perform calculations, but the speed at which calculations must be completed and the amount of calculations differs significantly. A real-time database is meant to perform calculations in real-time and is not made to keep information for long amounts of time. Designing real-time databases involves many more constraints on the size of the database and size of calculations — and many other considerations and factors — to ensure that calculations are done within a specified time. There are usually different deadline times, so the database can prioritize functions.
Traditional databases are made to hold data for long amounts of time and, while the data may have functions and calculations applied to them, the data is largely persistent. A real-time database is the opposite. The data are largely malleable, with very little remaining constant, and the database must be able to handle a very large amount of calculations. This means a traditional database will not work for a real-time application, because the design is completely different.
Perhaps the best example of a real-time database is a stock markets database. This database must be able to constantly change its values based on a large variety of factors and must remain accurate so businesses and investors thrive from transactions. Other real-time database examples include air-control databases, medical databases and scientific analysis databases.
When a traditional database is designed, the programmer creates a framework where information can be stored and programs a relatively small number of constraints. Real-time databases need to have a very large number of constraints to limit the amount of information they hold and the amount of transactions they can do, so the calculations can be performed quickly. This is because database speed is dependent on the amount of data held and the amount of functions working simultaneously. Most real-time databases are idiosyncratic, or cannot be integrated with other databases because they are highly specialized for one topic.
To meet temporal constraints, or time-based calculation needs, there are three priority levels placed on functions: hard, firm and soft. This goes in order from fastest to slowest, so the database knows what to work on now and what can wait. While all functions can be placed on the hard priority, this can cause a large real-time database to crash because of overloads.