Historically, the goal of most database servers has been to maximize safety, that is, to make sure that data is not lost due to a power failure or other problems. These database servers use “strict durability”. This approach is appropriate for many types of data, such as accounting data, where it is often unacceptable to lose track of even a single transaction.

Some database servers have been designed to maximize performance, without regard to safety. Performance over safety is acceptable in situations where, for example, you need to only sample data, or where the server can simply operate on the most recent set of data, regardless of the size of that set. As an example, suppose that you have a server that contains statistical data about performance — for example, which computers experience the heaviest loads at particular times of the day. You might use such information to balance the load on your computers. This information changes over time, and “old” data is less valuable than “new” data. In fact, you might completely discard any data that is more than a week old. If you were to lose the performance and load balancing data, your system would still function. Furthermore, within a week you would have acquired a complete set of new data (assuming that you normally discard data older than one week). In this situation, occasional or small data loss is acceptable, and performance may be more important.

solidDB^® allows you to specify whether you want logging to be “strict” to guarantee that all committed data can be recovered after an unexpected shutdown, or “relaxed” to allow some recent transactions to be lost in some circumstances.