Durability relates to the 'D' in the so called ACID properties typically expected of OO and relational database systems.
ACID properties are particularly relevant to the management of data that relates directly to real world processes such as airplane reservation systems, or financial systems. In these cases, a transaction on a computer is associated with events in the real world. For example, when a client withdraws cash from an ATM. Clearly it is necessary for the database to correctly record all such withdrawals. This leads to the durability requirement. In practise this means that every transaction must be flushed to disk as part of the commit.
Dedicated database servers may employ disk write caching that promises to (eventually) write all data in the cache to disk. This requires a battery backed up cache, and other facilities, such as intercepting the RST signal to avoid clearing the cache, and use of ECM (Error Correcting Memory). Unfortunately "normal" hard-disks provide a disk write cache that is unsuitable for database servers, and this can't merely be fixed by using a UPS. Therefore it is necessary to disable the disk write cache. This may require changing jumpers on the hard-disk, or running special control software provided by the manufacturer.
Unfortunately, with no write cache, disk flush operations become very expensive. With an IDE drive at 5400 to 7200 RPM, there can be at most 50 to 70 disk flushes (i.e. transactions) per second. In many applications this is inadequate.
By contrast the LSS focuses on the management of data that doesn't (in a transactional sense) relate to real world processes. Examples are editing of text documents, spreadsheets, statistical analysis, web browsing, GIS, multimedia databases, source code repositories and CAD. In these cases the durability constraints can be relaxed a little - by only flushing transactions to disk every few seconds. Atomicity is still required to protect the integrity of the data. However, a transaction only "commits" in the sense of defining an atomic unit of work, rather than demanding it go to non-volatile storage as part of the commit.
This of course means that a user may lose some edits on system failure, but losing at most a few seconds of work is fine for the type of data managed by the LSS.
In any case, an LSS transaction provides a FlushWhenClose() method to allow the transaction (and all previously committed transactions) to be flushed when the transaction is closed. The underlying LSS file is opened with no write through cache, so in theory all committed transactions will be durable.