plans for enabling hammerdb to fully run on aarch64

[abondarev84]

Hello,

I've found an old discussion from 2021 (a bit over 3 years ago) about running hammerdb on ARM Linux (#282).

Is there a plan or timeline for hammerdb to run on ARM Linux? has anything changed since the answer in the above discussion?

Thanks in advance

[sm-shaw]

Many thanks for re-raising this question and yes something has changed since the original discussion. The new version of Tcl/Tk version 9.0 has been released, and we are busy working on porting HammerDB to this release for both Windows and Linux x86_64 initially - this involves for example updating all the C extensions in the HammerDB lib directory (that can be built from source using Bawt in the build directory) - this is in progress and a HammerDB prototype is already running very well with Tcl/Tk 9 on Linux (with all compiled extensions) - although there is more work to do and a lot more testing.

And yes Tcl/Tk 9 supports aarch64 for both Linux and Windows as described by this thread https://sourceforge.net/p/tcl/mailman/tcl-core/thread/CAA40n-U3E%2B%2B0QbS3egQEP_a1fYvhE3suEFjxghOpt_2GtaSNRQ%40mail.gmail.com/#msg58820782 It is important that we maintain full compatibility and functionality for both Linux and Windows on potential platforms so it looks like Tcl/Tk 9.0 does do that - I know you mention Linux but having Windows on the same platform is important.

So, once the x86_64 version of HammerDB with Tcl/Tk 9.0 is released, this provides the potential platform to build for aarch64. This could be contributed, although if the demand is there once the x86_64 versions then this could also potentially become a core team project to provide pre-built binaries and is a good topic for discussion at the TPC-OSS subcommittee to decide if this is desirable and potential timelines.

So in summary, aarch64 is not planned for HammerDB v4 and therefore will not be immediate, the next version will be based on Tcl/Tk 9 so this will come first for x86_64 (and this is currently on the committed timeline) but if the demand is there subject to TPC-OSS subcommittee discussion then it could be a core project to provide an aarch64 release starting at the next major version. If this is the case, an issue will be created to progress. (Note, previously having aarch64 clients has been a blocker as most client development systems are x86_64).

[mithunkrb]

Hi @sm-shaw, thank you for sharing the update! Just curious—has there been any further progress on this? By any chance, is there an alpha, beta, or pre-release version of HammerDB for Windows ARM64 available yet? (Apologies for the optimism!)

[sm-shaw]

Hi, there are no alpha, beta or pre-release versions of HammerDB for ARM64 at present. This has been intentional as the priority goal has been to complete HammerDB v5.0 for x86-64 first and then building an ARM port based on this release. The good news is that the PR for v5.0 has been made here #777 and pre-release x86-64 binaries have been shared within the TPC for testing. Therefore subject to approval and further release related tasks, HammerDB v5.0 (for x86-64) should be released in the near future. (You can already build this from source now that the PR is available) Only after this point will ARM ports be looked at. I do note though that you ask for Windows on ARM and therefore the interest is for both ARM Linux and Windows builds.

[jsrz]

I just want to post so that I can 👍 the request for an Arm build of HammerDB. :)

It's looking like the project is slowing inching towards supporting Arm, which is good to hear. Just posting to say "yes, Arm please 👍"

[sm-shaw]

Thanks for the 👍 — it’s on the radar and we do have Arm hardware for initial exploration in 2026.

We’re definitely seeing a lot of interest in Arm across cloud and on-prem, so having first-class support in HammerDB makes sense.

The main focus for us is doing it properly, so rather than just “making it compile” — ensuring full validation across workloads, packaging, and performance characterisation. - This is what takes time.

What would really benefit would be if there was interest from Arm side in collaborating or helping accelerate that work, I’d be very happy to talk. As I learned from my time at Intel proper platform support is always strongest when the silicon vendor is involved.

Once HammerDB is properly enabled on Arm, there’s a real opportunity to explore how database workloads scale and behave on the platform. We’ve consistently seen that performance characteristics are highly architecture specific, and understanding those is where meaningful gains are often found. Here is an example with MariaDB on x86 https://www.youtube.com/watch?v=DrmZJLuG0fg

[jsrz]

I might be able to nudge loose some support from Arm. What sort of support do you have in mind? That would help me sort out who I need to discuss with internally.

[sm-shaw]

A high-level overview is as follows:

(1) Decide the scope of Arm support
(2) Port the C packages and get Bawt build process to work end-to-end.
(3) Test TPROC-C and TPROC-H for functionality with available options
(4) Validate performance to ensure workloads have the trust people expect of HammerDB.

In detail
(1) HammerDB supports multiple database client libraries, so “Arm support” effectively means ensuring the entire stack builds and runs natively. The databases currently supported are:
Oracle Database Linux/Windows
Microsoft SQL Server Linux/Windows
IBM Db2 Linux/Windows
PostgreSQL Linux/Windows
MariaDB Linux/Windows
MySQL Linux/Windows
That is 12 client environments all written in C compiled with gcc on Linux and MSVC on Windows. The very first step is deciding which ones are actually available and which ones to support. e.g. I don't believe Db2 has any Arm support?

(2) Next step, HammerDB already has a Setup process (BAWT) that pulls the required packages and builds the components needed for each database driver above. So the task is to port this process to have Arm as an option. This means ensuring that all required packages will build, the example below is for Linux, there is a different set for Windows. All are in C, everything is open source. Where there is an S suffix it is a static build in addition to the dynamic. As an example this took appx 3 months to port and test everything from Tcl8 to Tcl9. its hard to know whether this will be easier or more difficult porting to Arm.

#Builds Tcl, Tk, Starkit and Tcl/Tk packages, which do not depend on 3rd party libraries.
# On Windows all libraries can be compiled with MSys/MinGW.
# Setup LibName         ZipFile                        BuildFile           BuildOptions
# Tcl/Tk, stubs and manual.
Setup Tcl                Tcl-[GetTclVersion].7z         Tcl.bawt
Setup TclS               Tcl-[GetTclVersion].7z         TclS.bawt
Setup Tk                 Tk-[GetTkVersion].7z           Tk.bawt
Setup TkS                Tk-[GetTkVersion].7z           TkS.bawt
# Compiled Tcl packages.
Setup expect             expect-5.45.4.1.7z             expect.bawt	
Setup tkpath             tkpath-0.4.1.7z                tkpath.bawt
Setup tkblt              tkblt-3.2.24.7z                tkblt.bawt
Setup tclpy              tclpy-0.4.1.7z                 tclpy.bawt
Setup tclpyS             tclpyS-0.4.1.7z                tclpyS.bawt
# Compiled Tcl Database interface packages.
Setup oratcl             oratcl-4.6.1.7z                oratcl.bawt	
Setup mariatcl           mariatcl-0.1.1.7z            mariatcl.bawt	
Setup mysqltcl           mysqltcl-3.052.1.7z            mysqltcl.bawt	
Setup db2tcl             db2tcl-2.0.1.1.7z              db2tcl.bawt	
Setup pgtcl              pgtcl-2.1.1.1.7z               pgtcl.bawt	
# Pure Tcl/Tk packages.
Setup awthemes           awthemes-10.4.0.7z             awthemes.bawt
Setup ticklecharts	     ticklecharts-3.2.8.7z	        ticklecharts.bawt

So the 2nd milestone is validating that this process works on Arm systems and we can build GUI, CLI and Web Service on these platforms.

(3) The 3rd stage is to verify the TPROC-C and TPROC-H workloads execute correctly across all supported databases with all of the available options and to ensure everything that was ported is stable and robust.

(4) Once the functional side is in place, the final and arguably most important part is ensuring that the workloads are valid and can be trusted. HammerDB has broken multiple database drivers including commercial ones in the past so there is potential for 3rd party failures in the stack that need resolving. If there are no issues here all of the supported databases need to be tested to ensure that they perform as expected.