Open Source Amazon Timestream 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.

TDengine stores the data that billions of sensors, meters and vehicles produce every second. Generic databases buckle under that shape of workload, where writes never stop, queries are almost always bounded by time, and distinct collection points run into the billions.

The engine is written in C and organizes readings through super tables, partitioning by time interval and separating storage from compute. Caching, stream processing, data subscription and an AI agent named TDgpt are built into the same server, so the stack needs no separate cache, queue and stream processor alongside it.

Several parts of the design are worth knowing before you commit to it.

• High cardinality: the engine addresses the cardinality limit that constrains other time series databases, supporting billions of data collection points.
• Cloud native distribution: sharding, partitioning, RAFT and Kubernetes deployment let one cluster run on public, private or hybrid infrastructure.
• TDgpt: the built in AI agent connects time series foundation models, large language models and classical algorithms for forecasting, anomaly detection, imputation and classification.
• Simplified operations: administrators deploy and maintain less machinery, while developers get a simple interface and integrations with third party tools.
• Open core: the cluster feature and the AI agent are released under open source licenses, with over 730,000 instances reported running.

Builds are tested primarily on Linux, with macOS supported for local development and Windows limited in the open source tree. Install from a container, a package or Kubernetes, or build from source with CMake 3.21. Four gigabytes of RAM and two of free disk are the recommended floor.

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.

Collection, storage and analysis of time series data sit in one system with Apache IoTDB, a database shaped by industrial internet of things workloads, where millions of low-power devices write continuously and the accumulated dataset still has to answer complex queries.

Storage builds on TsFile, a columnar file format designed for time series, which is how the project reaches a high compression ratio on disk and keeps hardware cost down. The system runs on Windows, macOS and Linux and requires Java 17 or newer, with versions up to 25 verified.

The design answers a handful of recurring industrial problems.

• Flexible deployment: a one-click installer for cloud platforms or terminal devices, plus a tool that synchronizes data between the two.
• Directory structure: time series from complex device hierarchies organize efficiently, with fuzzy search across a large catalog of series.
• Query semantics: time alignment across devices and measurements, frequency domain transformation and aggregation over the time dimension.
• Familiar interfaces: a SQL-like language, the standard JDBC API, a command-line client and CSV import and export tools.
• Ecosystem integration: Hadoop and Spark for analysis, Grafana for visualization.

Before starting a node, raise the maximum open file count to 65535 and, on Linux, set somaxconn to the same value, or the server may fail to start or log connection resets. Docker users apply those limits on the host machine. Building from source additionally needs Maven 3.6 or later. The project is developed at the Apache Software Foundation, with issues tracked in Jira.

Three observability signals usually mean three backends, three query languages and no way to join across them. GreptimeDB puts metrics, logs and traces on a single columnar engine over object storage, sharing one table model of tags, timestamp and fields, so signals sharing a service, host or trace identifier correlate in SQL.

Compute and storage are disaggregated. Object storage on S3, GCS, Azure Blob or an S3-compatible endpoint holds the data, while memory and local disk caches keep recent and frequently queried rows near compute. A standalone binary suits development, and the distributed mode splits into frontend, datanode, metasrv and an optional flownode for streaming computation.

Migration can move one signal at a time rather than all at once.

• Ingestion: OpenTelemetry, Prometheus Remote Write, Loki Push, Elasticsearch bulk, InfluxDB line protocol and gRPC.
• Query: SQL and PromQL, Jaeger-compatible trace queries, and the MySQL and PostgreSQL wire protocols.
• Built in: retention policies, downsampling, continuous aggregation, explicit table partitioning and inverted, skipping and fulltext indexes.
• Compatibility limits: LogQL and most Elasticsearch APIs are not covered, and PromQL has documented gaps.
• Edition boundary: read replicas, workload isolation and automated repartitioning belong to the commercial Enterprise build.

The Apache-2.0 core includes cluster deployment, object storage, the flow engine and every ingestion protocol listed above, though repartitioning, region migration and index creation are manual. A Docker image starts a standalone instance with a dashboard on port 4000, and building from source needs a nightly Rust toolchain, protobuf 3.15 or later and C and C++ build essentials.

CrateDB is a distributed SQL database for storing and analyzing very large volumes of data in real time. It dissolves the usual choice between the query language of a relational database and the scaling behavior of a NoSQL store.

Clients connect over the PostgreSQL wire protocol or an HTTP API, so existing SQL tools and drivers work unchanged. A distributed execution engine parallelizes each query across the whole cluster, and modest clusters ingest tens of thousands of records per second.

The database absorbs several jobs that usually need separate systems.

• Dynamic schemas: tables accept new columns and queryable objects, adding document-oriented behavior on top of relational SQL.
• Time series and search: time series data, real-time full-text search and geospatial types with their own search capabilities.
• Cluster automation: auto-partitioning, auto-sharding, auto-replication, self-healing and auto-rebalancing.
• User-defined functions: extend the SQL surface with functions of your own.
• Admin UI: a browser console for running SQL and watching the cluster.

CrateDB suits containers and scales horizontally on ephemeral virtual machines with no shared state, whether on Kubernetes, AWS or Azure. The same engine runs on a personal computer, across multi-region hybrid clouds and out at the edge. An official Docker image starts a single node in one command, and Crate.io, which maintains the project, also offers a fully managed database as a service.