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

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.

6

Unfortunately no comments have been made. I could not find users who had recently posted or comment about derby related topics.

Moving to sqlite with upgradetool might be possible. Also wondering if it is worth all the effort as it seems about nobody is using it. Not using it myself so testing and doing all the work is a pita.

7

if there’s any user, they could simply not upgrade, and work on migrating first before upgrading.

I’m not sure an upgradetool is worth the effort. For all we know, there could be zero user of it right now.

8

This is where it would be nice to have telemetry - just reporting anonymous usage per feature.

I’m not familiar with this topic, but I’d imagine that when properly anonymized I don’t see why anyone should be objecting to it, there should be zero privacy concern, no?

9

There is, as the ip that uploads the data makes it possible to link data to a location. Knowing the used bindings, you know the attack surface.
An opt-in would reduce the concerns, but still. Up to now it seems this was non-negotiable.

We might already be able to get statistics from the jfrog jar downloads. That allows us to atleast identify some bindings that are being installed, bas d on the used dependency’s
Not sure if @florian-h05 is able to see that kind of download counters.

10

can’t we simply not log the ip? Or anonymize it → use a hash of the IP instead. This would let us deduplicate the logs and give us a real count, timestamp (when it was last used).

Doesn’t this have the same ip log?

11

Usually this discussion is not about what you actually log, but about the potential. I personally would like to have such feature. Might start this discussion again and see what happens

12

You can view the download counters without an account, e.g. JDBC Add-on or Apache Derby Driver.

I suppose the JDBC plugin pulls the driver from the add-on KAR or our JFrog?

13

Just FYI, Spring framework marked Derby support as deprecated this summer, see

They now recommend H2 or HSQLDB

14

Hehe exactly the reason for this thread, see startpost.