Comparing GridDB & MongoDB for Time Series Data

If you are choosing a database for time series data, GridDB and MongoDB are two of the most established options. In 2026 they make a surprisingly different bargain with you. GridDB is a purpose-built time series database whose Community Edition can query and analyze your full data history. MongoDB is a general-purpose document database that added native time series collections in version 5.0, keeping the document model and the rest of the MongoDB feature set available alongside them.

We took GridDB Community Edition and MongoDB Community Server, ran through the workloads that matter to ingest, retention, and query history, and this page lays out the differences honestly so you can decide for yourself.

A note on editions before we start. This comparison is primarily between GridDB Community Edition and MongoDB Community Server, since those are the two free, self-hosted, open source editions. Where the managed services (GridDB Cloud and MongoDB Atlas) change the answer, we say so. MongoDB’s time series collections have been available since 5.0 and are in the Community edition, not held back for commercial tiers.

At a Glance

Architecture: Purpose-Built vs General-Purpose

Both databases are well-engineered. They optimize for different things.

GridDB was designed by Toshiba specifically for IoT telemetry. Its storage engine, container model, and built-in functions all assume you are ingesting large volumes of timestamped data at high frequency and querying it by time. It runs an in-memory-first architecture, a hybrid of memory and disk, tuned for high write throughput on this kind of data. The design assumes high-frequency data from many devices, retained and queryable over time.

MongoDB approaches time series as a specialized capability layered onto a flexible document store. When you create a time series collection, MongoDB organizes writes so that data from the same source is stored alongside other data points from a similar point in time, in an internally optimized bucketed format. Under the hood, MongoDB treats time series collections as writable non-materialized views backed by an internal collection.

The practical consequence cuts both ways. MongoDB’s bucketing gives you real time series efficiency without giving up the document model, so one system can serve both your operational data and your telemetry. GridDB’s narrower focus means the whole engine, not a collection type within it, is built around the time series access pattern.

Data Model: Key-Container vs Time Series Collections

GridDB uses a Key-Container model. Each data source, typically a sensor or device, gets its own container, addressed by key. A TimeSeries container uses a TIMESTAMP column as its row key. Data is strongly typed, which means schema is fixed up front and enforced. Through the SQL interface, a container is simply a table.

MongoDB stores each measurement as a BSON document inside a time series collection. Each document carries a required timeField, an optional metaField identifying the source, and any number of measurement fields. The schema is flexible, so documents in the same collection can carry different fields entirely.

The difference is clearest at creation time.

MongoDB

db.createCollection("sensors", {
  timeseries: {
    timeField: "timestamp",
    metaField: "sensorId",
    granularity: "seconds"
  },
  expireAfterSeconds: 2592000  // auto-remove data after 30 days
})

GridDB (SQL interface)

CREATE TABLE sensors (
  ts     TIMESTAMP PRIMARY KEY,
  value  DOUBLE
) USING TIMESERIES
WITH (expiration_type='ROW', expiration_time=30, expiration_time_unit='DAY');

Which model suits you depends on your data. If every device emits the same fixed set of readings, GridDB’s typed containers give you enforcement and compactness. If your payloads vary by device generation, firmware version, or vendor, MongoDB’s per-document flexibility saves you from schema migrations.

Query Interfaces: SQL vs Aggregation Pipeline

This is often the deciding factor, and it is worth being precise because both databases are widely misdescribed here.

GridDB offers two interfaces. TQL is a lightweight query language for the NoSQL side, and the SQL interface is SQL-92 compliant over standard JDBC and ODBC. A team that already knows SQL writes SELECT, JOIN, GROUP BY, and window queries without learning anything proprietary. The often-repeated claim that GridDB cannot do JOINs applies to TQL, not to the SQL interface.

MongoDB uses its own Query API and aggregation pipeline rather than SQL, and for time series work it is genuinely capable. $setWindowFields gives you window functions such as moving averages and rank. $densify fills in missing time points and $fill populates their values by interpolation or carry-forward. $dateTrunc handles time bucketing for downsampling.

The tradeoff is portability of skills and tooling. These are MongoDB-specific constructs, and a team standardized on SQL and SQL-based BI tools will face a learning curve. Atlas offers a read-only SQL interface for BI use cases, but that is a managed-service feature and it is read-only.

The Update Restriction

This is the difference that matters most between the two for operational workloads, and the one most likely to surprise people coming from a general-purpose MongoDB collection.

MongoDB time series collections are designed around the assumption that telemetry is append-only. That assumption is enforced. Update commands must match only on the metaField value and can modify only the metaField value. Your update document can contain only update operator expressions, updates must be multi-document (multi: true or updateMany()), and upsert: true is not allowed. Deletes are supported and follow similar matching rules.

Separately, you cannot write to a time series collection inside a multi-document transaction, though reads within transactions are supported.

For a pure telemetry pipeline, none of this matters. Sensors emit readings, you never go back and edit them, and TTL handles the aging out. But a large share of real deployments do need corrections: a miscalibrated sensor whose readings need rescaling after the fact, a backfill that overwrites provisional values with settled ones, an ETL job that needs to be idempotent and therefore wants upserts. On MongoDB time series collections those patterns require a workaround, typically deleting and reinserting, or staging corrections in a separate regular collection.

GridDB places no equivalent restriction on updating measurement values. If your workload involves in-place correction of individual readings, or writes that need to participate in transactions, test that path early on both databases rather than discovering it late.

Scalability: Where the Free Editions Differ

It is worth being precise here, because MongoDB has the advantage in the free edition and we would rather say so than have you find out later.

MongoDB Community Server includes both replica sets and sharding. You get high availability and horizontal scale-out without paying for a commercial license. For time series collections specifically, the recommended practice is to include the metaField in the shard key so that data from the same source stays co-located. A few constraints apply: shard keys containing the timeField are deprecated as of 8.0, zone sharding is not supported for time series collections, and resharding a time series collection became available only in 8.0.10. MongoDB 8.0 also brought substantial improvements to sharding speed and cost.

GridDB Community Edition is single-node. Multi-node clustering, replication, and automatic failover are part of the commercial Advanced Edition and of GridDB Cloud. The underlying architecture is a distributed shared-nothing design built for large-scale ingest, but you reach it through the commercial editions, not the free one.

So if clustering or high availability on a zero-cost license is a hard requirement, MongoDB Community meets it and GridDB Community does not. If you are comparing commercial tier to commercial tier, both scale horizontally and the comparison comes back to workload fit.

For either database, benchmark against a representative slice of your own workload rather than relying on general throughput claims. Results depend heavily on cardinality, batch sizes, and query patterns.

Licensing

GridDB ships the server under AGPL v3 with clients under Apache 2.0. AGPL imposes obligations on your application code: the copyleft only triggers if you modify the GridDB server itself and offer that modified server as a network service, but organizations with blanket AGPL bans should note this. Commercial Standard, Advanced, and Vector editions are available, as is the managed GridDB Cloud.

MongoDB uses the SSPL for the server, with drivers under Apache 2.0. The SSPL is not an OSI-approved open source license, and it is more aggressive than AGPL in one specific direction: it targets organizations offering the database itself as a service. For the overwhelming majority of users, who are building an application on top of MongoDB rather than reselling MongoDB, it imposes no practical burden. But it has been enough to get MongoDB removed from some Linux distribution repositories, and some enterprise legal teams treat SSPL as disqualifying on principle.

Neither license is a problem for a typical internal application. Both are worth a five-minute conversation with legal before you commit.

Performance

GridDB’s in-memory-first design and per-container layout favor high-frequency ingestion and per-device range scans across the full dataset. MongoDB’s bucketed storage format substantially narrows the gap against general-purpose document storage, and its compound metaField and timeField index serves the common “one source over a time window” query well.

Rather than repeat vendor claims, we would point you at the published benchmark work and, more importantly, at your own workload. Cardinality, batch size, payload shape, and query mix move these numbers more than any architectural difference does.

Ecosystem and Operations

MongoDB wins on ecosystem breadth, and it is not close. Official drivers for essentially every language, one of the largest developer communities in the industry, extensive learning material, mature tooling such as Compass and the BI Connector, and Atlas as a fully managed global service. If hiring pool and tool availability are priorities, this is a real and durable advantage.

GridDB’s ecosystem is narrower but aimed squarely at the IoT stack: official clients for Java, Python, C and C++, Go, Node.js, Ruby, PHP, and Perl, a REST/HTTP Web API, a Kafka Connect connector, and integrations with Grafana, Fluentd, Telegraf, MQTT, and Node-RED, plus an Apache Arrow interface for analytics. These are the components most IoT and observability pipelines are actually assembled from.

When to Choose Which

Choose GridDB if:

• Time series and IoT telemetry are your core workload, not a side workload
• Your team works in SQL and wants JDBC/ODBC access from existing BI tooling
• You need to update or correct individual measurement values in place
• You want writes that can participate in transactions
• You are deploying on-premises or at the edge, where a compact resource footprint matters
• You want purpose-built time functions rather than a general-purpose framework adapted to time series

Choose MongoDB if:

• Time series is one workload among several and you want a single system for all of it
• Your measurement payloads vary by device, firmware, or vendor and a flexible schema saves you migrations
• You need clustering and high availability on the free edition
• Your team is already fluent in the aggregation pipeline, or already runs MongoDB or Atlas
• Ecosystem breadth, tooling, and hiring pool are high priorities
• Your telemetry is genuinely append-only, so the update restrictions never bind

FAQ

Does MongoDB support SQL for time series data?

Not for writes, and not in the self-hosted Community edition. MongoDB uses its Query API and aggregation pipeline. Atlas provides a read-only SQL interface aimed at BI tools. GridDB provides a full SQL-92 interface over JDBC and ODBC in the free edition.

Can I update a measurement value in a MongoDB time series collection?

Not directly. Updates can only match on and modify the metaField, upserts are not allowed, and writes cannot occur inside a transaction. Correcting a measurement value generally means deleting and reinserting the document.

Can GridDB Community Edition run as a cluster?

No. GridDB Community Edition is single-node. Multi-node clustering, replication, and failover are part of the commercial Advanced Edition and GridDB Cloud.

Can MongoDB Community Server run as a cluster?

Yes. Replica sets and sharding are both included in the free Community Server, which is a genuine advantage over GridDB Community Edition on this specific point.

Is MongoDB open source?

Partially. The server is under the SSPL, which is not OSI-approved, though the source is available. The official drivers are Apache 2.0. In practice the SSPL only creates obligations for organizations offering MongoDB itself as a service, but some legal teams treat it as disqualifying regardless.

Do MongoDB time series collections support TTL and secondary indexes?

Yes to both. Automatic expiry is configured with expireAfterSeconds, and since version 6.0 secondary indexes can be created on any field, in addition to the compound metaField and timeField index MongoDB creates automatically.

Which is faster?

It depends on the workload. GridDB’s purpose-built engine favors high-frequency ingestion and per-device range scans over the full dataset. MongoDB’s bucketed format performs well on the common source-plus-time-window query and lets you keep telemetry alongside your operational data. Cardinality, batch size, and query mix will move your results more than the architectural difference will, so benchmark with your own data.