Skip to content

KX Sensors on KDB-X

This page explains what changes when KX Sensors runs on KDB-X, and which KDB-X capabilities are available to your deployment.

As of v3.3, KX Sensors runs on KDB-X instead of kdb+ 4.1. KDB-X is the next generation of the database at the core of KX Sensors.

KX Sensors still runs on q, with the same storage and query performance. This is a change of foundation, not a change of interface: your schemas, APIs, packages, and SAPI clients continue to work as before.

What the change brings is access to the KDB-X module ecosystem — a modular architecture, broader language support, and native support for modern data formats and web services.

Available now compared to planned

Some KDB-X capabilities are integrated with KX Sensors in this release, such as the REST server framework. Others are available at the KDB-X level and need further integration work before sensor workloads can use them. Each section below states which applies.

Licensing

Your existing KX Sensors license continues to work on KDB-X. As in earlier v3 releases, individual features are gated behind license feature flags, so depending on the features you use — RT in a multi-node deployment, KX Dashboards, or REST — your license may need to be reissued with additional flags. To have your license reissued, contact KX.

Module framework

Modules are the unit of encapsulation in KDB-X, and they're the mechanism by which the platform is extended. Rather than adding capabilities to the core database, KDB-X packages them as modules that a deployment loads as needed. For how the framework itself works, see the KDB-X module framework overview.

For KX Sensors, the framework makes the product easier to extend and adapt as you:

  • Scale to larger data volumes.
  • Integrate new data sources and formats.
  • Develop custom workflows and applications.
  • Add AI capabilities without modifying the core product.
  • Reuse components consistently across deployments.

Entitlements

Some KDB-X modules and capabilities require additional licenses or entitlements. Confirm availability with KX before you include them in a customer solution or commercial offering.

Polyglot access

KDB-X supports q, Python, and SQL within a single platform, and lets you combine them in the same workflow. Use q for high-performance time series processing, Python for data science and integration work, and SQL for familiar relational access to the same data.

SQL interface

The KDB-X SQL module translates SQL statements into q expressions at runtime, which gives SQL users a familiar way to query KDB-X data.

SQL interface limitations

The interface currently supports a subset of ANSI SQL. It also doesn't natively process a single query across all three KX Sensors storage tiers (RDB, IDB, and HDB), so a SQL query is scoped to the tier it runs against. A future KX Sensors SQL gateway is planned to route queries across tiers and merge the results into a unified response.

Web service integration

REST server framework

The KDB-X REST server module maps REST endpoints to q functions. KX Sensors uses this framework to expose your public APIs over REST: it translates incoming requests, submits asynchronous SAPI calls, and routes them through the KX Sensors Gateway. This gives external applications and services a standard integration layer.

For how to enable and use REST in KX Sensors, see Call APIs over REST.

kurl REST client

The KDB-X kurl module provides synchronous and asynchronous REST client functionality from q, so KX Sensors processes can call out to cloud services, third-party APIs, and external applications.

Vector search and AI

KX Sensors can use the KDB-X vector search and AI libraries across structured, unstructured, and time series data. Supported search patterns include similarity, fuzzy, hybrid, metadata-filtered, and advanced time series search.

You can apply these patterns to sensor workloads such as anomaly investigation, event matching, root-cause analysis, contextual search, and AI-assisted applications.

Parquet

The KDB-X Parquet module (pq) provides the foundation for native Parquet support. It queries large Parquet datasets directly using row group pruning and virtual tables, supports partitioning and object-store access, and lets you use q or SQL against Parquet files alongside in-memory and partitioned tables. Columnar compression such as snappy and zstd keeps the data queryable while reducing storage costs.

Not yet integrated with KX Sensors

Parquet support is currently available at the KDB-X level only. Future work will complete the integration with KX Sensors, letting sensor workloads use Parquet as a first-class format for scalable storage, analytics, and interoperability with other data platforms.

Object storage

The KDB-X Object Storage module lets KDB-X processes read supported cloud object storage data as if it were local. This separates compute from storage, so you can query large historical datasets without keeping all of the data on block storage.

Not yet integrated with KX Sensors

Object storage access is currently available at the KDB-X level only. A future KX Sensors release is planned to support tiering older historical data to lower-cost object storage, such as Amazon S3 or Azure Blob Storage, while retaining recent real-time data on SAN or block storage. This is expected to reduce storage costs for large-scale, long-retention deployments.

Next steps

  • KDB-X documentation — the full reference for the underlying database and its modules
  • Install KDB-X — if you want to evaluate KDB-X outside a KX Sensors deployment, the KX Sensors installer provides the binary for you
  • What's new in v3 — the major differences between v2 and v3
  • Call APIs over REST — expose your APIs as JSON-over-HTTP endpoints
  • Key processes — the core KX Sensors processes and what they do