A subset of the SQL standard is supported. The main programming APIs are SQL and JDBC, however the database also supports using the PostgreSQLODBC driver by acting like a PostgreSQL server. It is possible to create both in-memory tables, as well as disk-based tables. Tables can be persistent or temporary. Index types are hash table and tree for in-memory tables, and b-tree for disk-based tables. All data manipulation operations are transactional. Table level locking and multiversion concurrency control are implemented. The 2-phase commit protocol is supported as well, but no standard API for distributed transactions is implemented. The security features of the database are: role based access rights, encryption of the password using SHA-256 and data using the AES or the Tiny Encryption Algorithm, XTEA. The cryptographic features are available as functions inside the database as well. SSL / TLS connections are supported in the client-server mode, as well as when using the console application. Two full text search implementations are included, a native implementation and one using Lucene. A simple form of high availability is implemented: when used in the client-server mode, the database engine supports hot failover. However, the clustering mode must be enabled manually after a failure. The database supports protection against SQL injection by enforcing the use of parameterized statements. In H2, this feature is called 'disabling literals'. Since version 1.1.111, H2 in-memory database can run inside the Google App Engine.
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. According to the H2 documentation, such problems are related not only to the DB engine design, but also to the storage caching mechanism. As storage devices use write cache in order to increase speed, in a situation of power failure, data in the device's cache is lost. 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. It is possible in some cases to force the storage to write cache frequently or even immediately using fsync which slows the writing process or one can accept that caching in the device buffer introduces some risk of data loss in case of power failure. 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 completely eliminate the chance of lost or inconsistent data in the event of a sudden power failure. Working with the OS and hardware settings to disable all caching so as to write data in real time can have significant impacts on performance in that only around 100 write operations per second would be achievable when using spinning disks. The H2 documentation makes an effort to describe in detail potential problems with durability resulting from the potential data loss of committed transactions in case of a 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. HSQLDB documentation references workarounds to a similar set of issues in their documentation. The Microsoft Knowledge Base describes the impact these issues, power failures, write caching, etc. can have on performance and durability. 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.
Utilities
An embedded web server with a browser based console application is included, as well as command line tools to start and stop a server, backup and restore databases, and a command line shell tool.
History
The development of the H2 database engine started in May 2004, and first published in December 2005. The database engine was written by Thomas Mueller. He also developed the Java database engine Hypersonic SQL. In 2001, the Hypersonic SQL project was stopped, and the HSQLDB Group was formed to continue work on the Hypersonic SQL code. The name H2 stands for Hypersonic 2, however H2 does not share code with Hypersonic SQL or HSQLDB. H2 is built from scratch.
