[citation needed] The database supports protection against SQL injection by enforcing the use of parameterized statements.

[citation needed] A simple form of high availability is implemented: when used in the client–server mode, the database engine supports hot failover (this is commonly known as clustering).

[7] The H2 documentation explains in detail several ways in which problems in underlying hardware and in particular power systems can impact durability of relational databases.

Administrators have then to assess the common trade off between speed and data loss risks in the context of the business requirements and must carefully consider the design of the power supply and UPS of critical servers.

The effectiveness of using fsync is limited by the fact that many HDD have write caching enabled by factory default in which case there is nothing about the design or settings of the database nor OS level commands that will be able to eliminate the chance of lost or inconsistent data in the event of a sudden power failure.

Considering the hardware limitations regarding preservation of data in the event of sudden power loss and the ineffectiveness of approaches commonly employed by developers to prevent these sorts of losses, many database engines do not by default call FileDescriptor.sync() nor FileChannel.force() nor fsync or equivalents for every commit because they significantly degrade system performance without significantly increasing durability.

[9] The Microsoft Knowledge Base describes the impact issues like power failures, write caching, etc.

[10] The knowledge base discusses the trade offs between performance and the vulnerability of disk write caching as well as settings that an administrator can use to balance these.