From kdb+ to KDB‑X

For the purposes of migration planning, it is best to think of KDB‑X as a newer generation of the same database engine and q language you already use, but with additional capabilities layered on top. For example, with KDB-X you get parquet integration, dual mode management of structured and non-structured datasets and access to the module framework.

KDB‑X is primarily a version progression rather than a fundamentally different technology. This is why, for environments already on 3.6+, the initial step can usually be treated as a binary swap, whereas 3.5 and older deployments must first address the same upgrade concerns they would face when moving to kdb+ 4.1. More on KDB-X here. 

The fundamental overview of an upgrade approach is:

• If you are on kdb+ 3.6 or later, an initial move to KDB‑X can typically be managed as a simple binary replacement of the q executable, updated KX licence, plus a small number of non‑user‑compatible change (NUC) checks.

• If you are on kdb+ 3.5 or earlier, you will first need to carry out data and code upgrades similar to those required for a move to kdb+ 4.1 before you can safely adopt KDB‑X.

This document sets out that distinction, explains what is required at a high level for older versions, and outlines how to approach the migration in a controlled and reversible manner.

The most important practical distinction for a KDB‑X migration is the current kdb+ version, and whether or not that version is <v3.6. 

For a full list of changes with each release, see the KX Releases page.

Systems on kdb+ 3.6 or later 

The on‑disk layout and language/runtime behaviour are already much closer to the versions underlying KDB‑X. 

For such environments, the initial KDB‑X migration can be approached as: 

• A binary replacement of the q executable. 

• A review of the small set of non‑user‑compatible changes (NUCs) introduced between your current version and the KDB‑X baseline (for example, stricter parsing, minor behavioural changes). 

In practice, this means a focused regression effort rather than structural changes to the historical database (HDB). 

Systems on kdb+ 3.5 or earlier 

These versions pre‑date several important changes in: 

• On‑disk data representation (e.g. certain nested/mapped types, enums, GUID handling). 

• Runtime semantics that can affect query behaviour. 

Before moving to KDB‑X, such estates should first be brought to a 4.x‑compatible state, which is essentially the same preparatory work required for a direct 3.5 → 4.1 upgrade. 

Only once the data and code base have been modernised to that level is it appropriate to introduce KDB‑X.

Data Intellect has practical experience with these upgrade journeys. We have worked with clients to upgrade legacy HDBs, identified and mitigated NUCs across multiple kdb+ releases, and developed tooling and repeatable processes to support this (for example, dataset upgrade utilities, validation scripts, and structured test packs). Organisations facing a move from ≤3.5 can therefore treat this as a well‑understood space where expert assistance and tooling are available.

Through our long‑standing collaboration with KX, Data Intellect remains aligned with the latest kdb+ and KDB‑X capabilities, ensuring that upgrade and migration approaches reflect current best practice.

As mentioned in the last section, for environments on kdb+ v3.5 or lower, an additional HDB preparation step is required before moving to KDB‑X. At a high level, this involves: 

• Identifying older representations in the HDB which are no longer ideal or supported in newer versions (for example, specific nested/mapped types or legacy encodings of enums and GUIDs). 

• Transforming those structures into forms compatible with a modern kdb+ / KDB‑X runtime. 

• Validating that: 

• • The upgraded HDB can be read cleanly by the newer binary. 

• • Key queries and analytics behave as expected before and after the transformation. 

A full list of changes in the v3.6 release, including those that affect on-disk data (particularly enumerations) can be found here.

This data upgrade work is best performed using purpose‑built upgrade utilities and smoke tests that provide an auditable record of: 

• Which dates and tables were touched

• What changes were applied

• Whether any anomalies were detected. 

If you are at or below kdb+ 3.5, expect a one‑time, controlled HDB preparation phase before the KDB‑X binary swap. Data Intellect can assist with this using existing tools and experience. 

Once you are on kdb+ 3.6 or later, and have completed the HDB preparation phase for older versions, the core migration step to KDB‑X can generally be viewed as a simple binary swap.

The recommended approach to this would, however, be one of caution and in-parallel testing. This is a standard approach to any upgrade, and not anything specific to KDB-X itself. This could include high-level steps such as:

• Install KDB‑X alongside your existing kdb+ installation, or within a safe dev or test environment
• In most cases, a new licence from KX will be required, which may include usage of a Community Edition licence
• Update your service definitions, scripts, or framework configuration (such as TorQ) so that: 
  • They invoke the KDB‑X q executable instead of the previous kdb+ binary. 
• Restart the stack using KDB‑X and perform: 
  • Basic connectivity and startup checks. 
  • A set of tests to validate that core queries and business flows behave as expected. 

On top of the binary swap, it is important to test normal operation at application‑level, especially when frameworks, such as TorQ are used. Data Intellects open-source TorQ framework is compatible with KDB-X, and also has some modifications to allow for usage with the KDB-X Community Edition. For more info, check out our recent blog.

In summary, an upgrade of an existing kdb+ system to KDB-X should be releatively straightforward and introduce no additional upgrade steps that would not already be required for existing versions, dependent on the version you currently run on.

For kdb+ 3.6 and later, the initial migration to KDB‑X can usually be treated as a simple binary replacement plus NUC‑driven regression testing. 

For kdb+ 3.5 and earlier, a preceding HDB and code upgrade phase is required, essentially mirroring the work needed to become compatible with kdb+ 4.1. 

For any assistance with kdb+ version upgrades, or a KDB-X upgrade, please reach out to Data Intellect for our expertise in supporting you in this area.