Open Source kdb+ Alternatives

InfluxDB 3 Core collects, processes, transforms and stores event and time series data. It aims at the case where readings must land and come back quickly enough to drive a dashboard, an alert or an interactive interface, covering sensor data, server and application monitoring, network telemetry, trading analytics and behavioral analysis.

The engine is written in Rust on Apache Arrow and DataFusion. Data persists as Parquet files on object storage from Amazon, Azure or Google, or on local disk with no other dependency, and the architecture is diskless by design. Writes arrive as line protocol over an HTTP API on port 8181.

Several traits separate this release from earlier InfluxDB generations.

• Query languages: SQL through the native engine, InfluxQL for older workloads, and Flight SQL.
• Response times: Under ten milliseconds for last-value queries and around thirty for distinct metadata.
• Embedded Python: A built-in virtual machine runs plugins and triggers next to the data.
• Compatibility: The 1.x and 2.x write APIs and the 1.x query API continue to work.
• Branch layout: Versions 2.x and 1.x live on their own branches of the same repository.

Core has been generally available since April 2025 and is licensed under MIT or Apache 2 at the user's choosing, with commercial code kept separate. Docker images, Debian and RPM packages and tarballs come from the InfluxData downloads page, and building from source is documented for contributors.

TimescaleDB is a PostgreSQL extension for high-performance analytics on time-series and event data. It removes the usual choice between keeping data in Postgres and getting columnar query speed, because both live in the same database and answer the same SQL.

An ordinary table becomes a hypertable, which partitions data into time-based chunks behind the scenes. With the columnstore enabled, rows can be inserted straight into columnar form, typically compressing by more than ninety percent, and queries then scan only the time ranges and columns they actually need.

A few constructs do most of the work.

• Hypertables: declared with a table option, they partition by time automatically as data arrives.
• Columnstore: columnar storage with vectorized execution, giving analytical queries over millions of rows in milliseconds.
• Time buckets: the time_bucket function aggregates rows into intervals such as an hour for summary values.
• Continuous aggregates: materialized views refreshed incrementally in the background, so only changed data is recomputed.
• Refresh policies: schedule how often an aggregate updates and which window it processes.

Getting started takes a one-line local install script or a Docker container publishing Postgres on a non-standard port to avoid clashing with an existing instance. Around 8GB of RAM is recommended, and you connect with psql or any Postgres client such as pgAdmin. The install script is for local development and testing, not production.

One SQL engine spans ingestion, stream processing and tiered storage in QuestDB, a low-latency time-series database built on open formats. That removes the usual split between a hot store for recent events and somewhere else for everything older.

The engine is zero-garbage-collection Java with C++ and Rust on the hot paths, and data lives in memory-mapped, time-partitioned columns. Queries run across all cores with SIMD and JIT-compiled filters, and nothing third-party sits on the data path. Storage is tiered across a parallel write-ahead log, native columnar partitions and Apache Parquet.

One engine covers the whole life of a series.

• Capture: ordered and out-of-order events in the millions per second, with deduplication and out-of-order correction built in.
• Compute: materialized views that aggregate by time slice, and live views running window functions on an in-memory tier.
• Query: time-series SQL extensions including SAMPLE BY, LATEST ON, ASOF JOIN, WINDOW JOIN and n-dimensional arrays.
• Retain: native partitions and Parquet queried through the same SQL, with Iceberg and Arrow keeping the data open to other tools.
• QWP: a binary columnar protocol over WebSocket that writes rows in and streams results back out as Arrow columns.

Docker starts an instance in one command, and Homebrew covers Apple silicon, though the bundled native libraries mean Intel Macs should use the image instead. Published benchmarks measure 19 million rows per second on ingestion and 220 million rows per second streamed into Arrow.

Timeplus Proton is a SQL pipeline engine for stream processing, analytics, observability and AI workloads, shipped as one C++ binary. It removes the JVM, ZooKeeper and the dependencies a streaming stack usually drags behind it, which is the argument for reaching past Apache Flink or ksqlDB.

The engine is powered by ClickHouse, extending its historical storage and compute with streaming. Materialized views are maintained incrementally and stay queryable inside Proton, so the same system feeds dashboards and applications rather than shipping every result elsewhere first. Thousands of SQL functions come with the ClickHouse lineage, and performance leans on SIMD optimization in C++.

SQL is the interface for everything, including the edges of the system.

• Sources and sinks: Kafka, ClickHouse, MySQL, Postgres, MongoDB, S3, Iceberg and OpenSearch, declared as external streams and tables.
• Windows and joins: tumble, hop and session windows, watermarks, and joins across several streams.
• Change data capture: CDC and data revision processing as part of the pipeline.
• Alerting and tasks: defined in SQL instead of a separate scheduler.
• User defined functions: extend the engine in Python or JavaScript.

Installation is a shell one liner, a Homebrew formula on macOS or a Docker image, and the binary is under 500MB with no dependencies, small enough for an AWS t2.nano. Published figures claim 90 million events per second and 4 millisecond end to end latency on a MacBook Pro with an M2 Max. Access it through the proton SQL shell, Python, Java and Go SDKs, a REST API or BI plugins.