Retirement of Apache Derby (persistence)

Add-ons Persistence Services
1

Apache Derby is an external project that has been used as one of the JDBC persistence options in openHAB for many years. As of October 2025, Derby is no longer actively maintained upstream. This means there will be no further functional or security updates.

This change directly affects Derby as a JDBC persistence option in openHAB. Continuing to ship and support an unmaintained external dependency increases risk over time and will eventually become a maintenance and security burden for the project.

For this reason, we would like to propose retiring the Derby persistence add-on from openHAB.

Proposed timeline
The proposed removal target is openHAB 5.2.0, which is currently planned for summer 2026. Derby would remain available throughout the 5.1.x release line, allowing users sufficient time to prepare and migrate.

Why this is being proposed
Derby persistence has seen very limited usage in recent releases. With the upstream project no longer maintained, the lack of security updates and fixes makes continued inclusion increasingly problematic. At the same time, openHAB offers several actively maintained persistence alternatives that are better aligned with current and future needs.

Migration considerations
If you are currently using Derby persistence, we would like to hear from you:

  • Are you actively using Derby today?

  • What is your use case?

  • Which persistence service would you consider migrating to?

  • Are there specific concerns or blockers that make migration difficult?

Your feedback will help us validate the proposed timeline, identify migration or documentation gaps, and determine whether additional transition support is needed.

Feedback requested
This is a proposal, not a final decision. We invite the community to comment on the planned removal in openHAB 5.2.0 and to share experiences, concerns, or migration needs related to Derby persistence.

note: to be clear this is not about the removal of JDBC, its only about Apache Derby, one of the possible persistence options of the JDBC add-on.

2

@lsiepel for the avoidance of doubt can you please confirm that this refers to the JDBC persistence service? (Or not..) .. And to be more specific, that you are not proposing to remove JDBC itself, bur rather just proposing to remove Derby as one of JDBC’s supported database options. Or??

image
image348Ă—743 16.9 KB

1 Like
3

PS you should probably “pin” this thread..

4

If it’s feasible, I would recommend setting up an automated migration to SQLite or some other jdbc embedded database. The migration could be performed by the upgradeTool.

Obviously, all the announcements and forewarning and everything else mentioned would also need to be done. But having a fallback for what I suspect will be a sizeable portion of Derby users who miss all that would be better than suddenly losing everything. I bet a good number of these users wouldn’t even notice.

5

The more i look into automated migration, the more challenging it appears, both technically and conceptually.

Hosted or managed installations would likely be out of scope due to their configuration requirements. Embedded or file-based setups are more feasible, but still limited, and it’s unclear whether any approach would work reliably across all supported host operating systems.

Any migration path would require extensive testing, as it directly affects users’ historical data, which may be very important to them. There’s also a real risk that existing backup routines silently break, or that users lack the knowledge or tools to manage their data after migration. Handling old but still valuable orphaned data is another open question.

Overall, the longer i think about this, the more risks and edge cases emerge. So far, I’ve also assumed (based on community posts for Derby) that the user base is relatively small, which makes it hard to justify such a costly and high-risk effort.