Comparing GridDB and TimescaleDB

If you are choosing an open source time series database to run on your own infrastructure, GridDB and TimescaleDB are two of the strongest candidates — and they take fundamentally different approaches. GridDB is a purpose-built time series database designed from the ground up for IoT-scale ingestion. TimescaleDB is a PostgreSQL extension that adds time series capabilities to a general-purpose relational database.

For most, GridDB is the better choice for high-volume IoT and sensor workloads. But TimescaleDB is a genuinely good database, and there are workloads where it can be the correct choice.

A note on scope: this comparison is GridDB Community Edition vs the open source edition of TimescaleDB

At a Glance

Architecture: Purpose-Built vs Extension

This is the most important difference, and a lot else flows from it.

GridDB was designed by Toshiba specifically for IoT telemetry. Its architecture is in-memory-first — memory is the primary store and disk is secondary — with an event-driven engine designed to minimize overhead per operation. Data is organized into containers, and in a clustered deployment (Enterprise Edition) distributed across nodes automatically. The database was built assuming millions of devices writing high-frequency data, and the design decisions reflect that.

TimescaleDB inherits PostgreSQL’s architecture: a row-oriented, disk-first, general-purpose relational engine. The extension adds hypertables — tables transparently partitioned into time-based chunks — plus a columnar compression engine for older data. This is a clever design that gets impressive results out of Postgres, but it is fundamentally an adaptation of an OLTP database to a time series workload, not a ground-up time series engine.

The practical consequence: GridDB’s hot path for sensor ingestion (append a timestamped row to a TimeSeries container, in memory) is shorter than TimescaleDB’s (full PostgreSQL write path — WAL, MVCC bookkeeping, buffer management). For write-heavy IoT workloads, that architectural difference shows up in throughput and resource efficiency.

The flip side: PostgreSQL’s general-purpose engine means TimescaleDB handles things GridDB doesn’t try to — complex multi-table joins, foreign keys against relational business data, window functions across arbitrary tables, and the full breadth of SQL.

Data Model: Key-Container vs Hypertables

GridDB uses a Key-Container model. Each data source — typically each sensor or device — gets its own container, addressed by key. TimeSeries containers treat the timestamp as the row key and provide time-specific operations (sampling, interpolation, time-window aggregation) natively. This maps one-to-one onto how real IoT systems are structured: a fleet of devices, each with its own schema and stream. Locating one device’s data never requires scanning an index shared with a million other devices.

TimescaleDB keeps the relational model: all sensors typically write into one wide hypertable with a device ID column, and chunks partition it by time. This is comfortable if you think in SQL, and it makes cross-device analytical queries natural. The trade-off is that per-device access patterns compete inside shared structures, and schema differences between device types get awkward (sparse columns, JSONB, or table sprawl).

Which model is better depends on your access pattern. Per-device reads and writes at high cardinality favor GridDB’s model. Ad-hoc analytics across all devices favor the relational model.

Scalability: Both Free Editions Are Single-Node

TimescaleDB’s multi-node support was deprecated and removed in version 2.14 (early 2024). Self-hosted TimescaleDB today is a single-node database: you scale by buying a bigger machine, and TigerData’s path to horizontal scale is their managed Tiger Cloud service. GridDB is the same story on the open source side: Community Edition runs as a single node, and multi-node clustering — automatic data partitioning, replication, and failover — is reserved for the commercial GridDB Enterprise Edition (and GridDB Cloud).

So basically, we recommend you choose your free edition on single-node merits, and treat clustering as a separate, paid decision for both. A single GridDB node is less limiting than it sounds — its hybrid memory-and-disk design supports very large datasets (on the order of tens of terabytes per node) — and the same vertical-scaling logic applies to a single large TimescaleDB node. The meaningful open source difference is what each gives you within that single node, which is where licensing comes in.

Licensing: Where the Open Source Editions Really Differ

Neither database is “just open source,” and the difference here is the crux of the open source comparison.

TimescaleDB ships in two editions. The Apache 2 edition is genuinely permissive open source — but it excludes most of what makes TimescaleDB compelling. Columnstore compression, continuous aggregates, and many recent performance features are part of the Community Edition, licensed under the Timescale License (TSL). The TSL is source-available, not OSI open source: it’s free to use as long as you are not offering TimescaleDB as a hosted database service, but it is a proprietary license with usage restrictions. In practice, the TimescaleDB you read about in benchmarks — compressed, with continuous aggregates — means accepting the TSL.

GridDB Community Edition licenses the server under AGPL v3 and the client libraries under Apache 2.0, and — importantly — its advanced features, including built-in time series compression, are part of that open source edition. AGPL is a true OSI-approved open source license, though a strong copyleft one: if you modify the GridDB server and offer it as a network service, you must publish your modifications. For the overwhelmingly common case — running GridDB unmodified as the database behind your application, talking to it through the Apache 2.0 client libraries — AGPL imposes no obligations on your application code. Organizations with blanket AGPL bans should note this; everyone else will find it a non-issue.

To summarize: GridDB CE gives you a purpose-built time series engine with its advanced features under an OSI open source license. TimescaleDB’s truly-open Apache edition is feature-limited, and its full capability is source-available (TSL) rather than open source. That — not clustering — is where GridDB’s free edition pulls ahead.

Performance

Both databases are fast, and both vendors publish benchmarks that favor themselves — including us. Rather than quote numbers here, we’ll note the architectural expectations and point you to reproducible tests.

GridDB’s in-memory-first design and per-container data layout favor high-frequency ingestion and per-device range scans — the core IoT pattern. TimescaleDB’s columnstore compression and vectorized execution (significantly expanded in the 2.26–2.27 releases) favor analytical scans over compressed historical data. The Time Series Benchmark Suite (TSBS) supports both databases, and we encourage you to run it against your own workload shape — benchmark results vary enormously with cardinality, batch size, and query mix.

TSDB_Evaluation_of_GridDB_QuestDB_and_TimescaleDB

Ecosystem and Operations

TimescaleDB wins on ecosystem. It is PostgreSQL, so every Postgres driver, ORM, BI tool, backup utility, monitoring exporter, and DBA skill set applies directly. If your team already runs Postgres, the operational learning curve is nearly zero.

GridDB’s ecosystem is smaller but covers the IoT stack well: official clients for Java, Python, C, Go, Node.js, and PHP; a Kafka Connector for streaming pipelines; a Grafana plugin for visualization; and integrations with Telegraf, Fluentd, and Logstash for telemetry collection. Operationally, GridDB requires learning its own tooling — there is no equivalent of the Postgres DBA talent pool.

When to Choose Which

Choose GridDB if:

• Your workload is high-frequency sensor/IoT ingestion at high device cardinality
• You want a purpose-built time series engine rather than an extension on a general-purpose database
• You want advanced features like compression under a genuine open source license, not a source-available one
• You value having both a fast NoSQL (TQL) path and SQL (JDBC) access to the same data

Choose TimescaleDB if:

• Your team already runs PostgreSQL and values that ecosystem above all
• Your workload mixes relational business data with time series and needs rich joins between them
• You’re comfortable with the TSL for compression and continuous aggregates, or plan to use Tiger Cloud

A note on scale for both: if you outgrow a single node, horizontal clustering is a paid step either way — GridDB Enterprise Edition on one side, Tiger Cloud on the other. Factor that into a long-term decision rather than assuming the free edition will scale out.

FAQ

Is TimescaleDB still open source?

Partially. The Apache 2 edition is open source but excludes columnstore compression, continuous aggregates, and most advanced features. The full-featured Community Edition uses the Timescale License (TSL), which is source-available but not OSI open source. Timescale Inc. rebranded as TigerData in June 2025.

Can free TimescaleDB run as a cluster?

No. Multi-node support was removed in TimescaleDB 2.14. Self-hosted TimescaleDB is single-node; horizontal scale requires their managed Tiger Cloud service.

Can free GridDB run as a cluster?

No. GridDB Community Edition runs as a single node. Multi-node clustering, replication, and failover are features of the commercial GridDB Enterprise Edition (and GridDB Cloud).

Is GridDB SQL-compatible?

Yes — GridDB provides a SQL interface via JDBC (its NewSQL interface) alongside its NoSQL API (TQL), and both are available in the open source Community Edition. Its SQL dialect is not as comprehensive as PostgreSQL’s, which is the trade-off for its purpose-built engine.

Which is faster?

It depends on workload shape. GridDB’s architecture favors high-frequency ingestion and per-device queries; TimescaleDB’s compression favors analytical scans of historical data. Run TSBS against your own workload — both databases support it.

---

GridDB Community Edition is free and open source. Download it from GitHub or get started with the quick start guide.