HyperSQL DB Release History

How Is HyperSQL Maintained and Who Supports It?

HSQLDB does not follow a versioned support lifecycle with published EOL dates. It is maintained by the HSQL Development Group -- a small, tight-knit team coordinated by a full-time maintainer -- and operates as a community-driven open source project under the BSD license. Only the current major line (2.x) receives active development; the 1.8.x line has been frozen for many years with no further updates.

Support is provided through community forums and the SourceForge tracker. There is no commercial SLA or guaranteed response time for the general public. The project does offer SupportWare -- an annual subscription program that funds ongoing development and grants subscribers priority on support requests and feature submissions. Teams embedding HSQLDB in commercial applications are encouraged to participate.

For current release status and documentation, refer to the official HyperSQL website and the HyperSQL User Guide.

What Are the Real Risks of Running an Outdated HSQLDB Version?

The risk profile for HSQLDB depends heavily on how you are using it. Most applications use HSQLDB as an embedded in-memory database for testing -- in that scenario, an old version is mostly an inconvenience. But for teams using HSQLDB with disk-based persistence (file: or res: catalog modes), or as a lightweight embedded production store, the stakes are considerably higher.

Risks specific to disk-based and production usage

What Happens When an HSQLDB Version Is No Longer Updated?

Unlike larger database vendors, HSQLDB does not announce deprecation windows or end-of-life transitions. A version simply stops receiving patches when the maintainer's focus moves on. There is no announcement, no migration deadline, and no LTS commercial option. The last published jar for that minor line is what you get, indefinitely.

For in-memory test usage, this is largely fine -- the JAR keeps working until a Java version upgrade breaks compatibility. In practice, the most common breaking point is a JRE major version upgrade: if your CI pipeline moves from Java 11 to Java 21, an old HSQLDB jar compiled without module support may begin emitting warnings or failing under strict module enforcement.

For disk-based usage, the situation is different. HSQLDB catalog files are tied to the engine version that created them. If you need to upgrade the engine to maintain Java compatibility, you must first export your data using the old engine and re-import using the new one. Skipping versions significantly increases the complexity of this migration, especially if the schema uses features that changed behavior between releases.

How Do You Check Your HSQLDB Version?

There are several ways to confirm the exact HSQLDB version in use, depending on your build tool and deployment mode.

Check via Maven

mvn dependency:tree | grep hsqldb

Look for both hsqldb and any transitive dependencies pulling in an older version from a framework like Spring Boot or Liquibase:

[INFO] +- org.hsqldb:hsqldb:jar:2.7.4:test

Check via Gradle

./gradlew dependencies --configuration testRuntimeClasspath | grep hsqldb

Check at runtime via JDBC

From a JDBC connection, you can query the engine version directly using standard SQL:

SELECT * FROM INFORMATION_SCHEMA.SYSTEM_SESSIONINFO
WHERE KEY = 'DATABASE VERSION';

Or using the DatabaseMetaData API:

DatabaseMetaData meta = connection.getMetaData();
System.out.println(meta.getDatabaseProductVersion());
// e.g. "2.7.4"

Check the JAR manifest directly

If you have the JAR on disk and want to verify its version without running it:

unzip -p hsqldb.jar META-INF/MANIFEST.MF | grep Implementation-Version

Note that if HSQLDB is pulled in transitively by Spring Boot, Hibernate, or another framework, the version in your test classpath may not be the one you specified -- always verify with dependency:tree to confirm no conflict is resolving to an unexpected version.