\nIf 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.\n<\/p>\n
\nWe 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.\n<\/p>\n
\nA note on editions before we start. This comparison is primarily between GridDB Community Edition<\/strong> and MongoDB Community Server<\/strong>, 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.\n<\/p>\n \nBoth databases are well-engineered. They optimize for different things.\n<\/p>\n \nGridDB<\/strong> 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.\n<\/p>\n \nMongoDB<\/strong> 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.\n<\/p>\n \nThe 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.\n<\/p>\n \nGridDB<\/strong> 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 \nMongoDB<\/strong> stores each measurement as a BSON document inside a time series collection. Each document carries a required \nThe difference is clearest at creation time.\n<\/p>\n MongoDB<\/strong><\/p>\n GridDB (SQL interface)<\/strong><\/p>\n \nWhich 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.\n<\/p>\n \nThis is often the deciding factor, and it is worth being precise because both databases are widely misdescribed here.\n<\/p>\n \nGridDB<\/strong> 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 \nMongoDB<\/strong> uses its own Query API and aggregation pipeline rather than SQL, and for time series work it is genuinely capable. \nThe 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.\n<\/p>\n \nThis 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.\n<\/p>\n \nMongoDB time series collections are designed around the assumption that telemetry is append-only. That assumption is enforced. Update commands must match only on the \nSeparately, you cannot write to a time series collection inside a multi-document transaction<\/strong>, though reads within transactions are supported.\n<\/p>\n \nFor 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.\n<\/p>\n \nGridDB 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.\n<\/p>\n \nIt 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.\n<\/p>\n \nMongoDB Community Server includes both replica sets and sharding.<\/strong> 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 \nGridDB Community Edition is single-node.<\/strong> 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.\n<\/p>\n \nSo 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.\n<\/p>\n \nFor 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.\n<\/p>\n \nGridDB<\/strong> 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.\n<\/p>\n \nMongoDB<\/strong> 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.\n<\/p>\n \nNeither license is a problem for a typical internal application. Both are worth a five-minute conversation with legal before you commit.\n<\/p>\n \nGridDB’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.\n<\/p>\n \nRather 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.\n<\/p>\n \nMongoDB wins on ecosystem breadth, and it is not close.<\/strong> 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.\n<\/p>\n \nGridDB’s ecosystem is narrower but aimed squarely at the IoT stack<\/strong>: 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.\n<\/p>\n Choose GridDB if:<\/strong><\/p>\n Choose MongoDB if:<\/strong><\/p>\n \nNot 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.\n<\/p>\n \nNot directly. Updates can only match on and modify the \nNo. GridDB Community Edition is single-node. Multi-node clustering, replication, and failover are part of the commercial Advanced Edition and GridDB Cloud.\n<\/p>\n \nYes. 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.\n<\/p>\n \nPartially. 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.\n<\/p>\n \nYes to both. Automatic expiry is configured with \nIt 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.<\/p>\n","protected":false},"excerpt":{"rendered":" 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 […]<\/p>\n","protected":false},"author":1,"featured_media":55513,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[121],"tags":[],"class_list":["post-55504","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"acf":[],"yoast_head":"\nAt a Glance<\/h2>\n
\n\n
\n \n<\/th>\n GridDB Community Edition<\/th>\n MongoDB Community Server<\/th>\n<\/tr>\n<\/thead>\n \n Vendor<\/td>\n Toshiba<\/td>\n MongoDB, Inc.<\/td>\n<\/tr>\n \n Architecture<\/td>\n Purpose-built time series database, in-memory-first with disk persistence<\/td>\n General-purpose document database; time series collections stored in an internal bucketed format<\/td>\n<\/tr>\n \n Data model<\/td>\n Key-Container (Collection and TimeSeries containers), strongly typed<\/td>\n BSON documents with a timeField and an optional metaField; flexible per-document schema<\/td>\n<\/tr>\n \n Query interfaces<\/td>\n NoSQL API (TQL) plus SQL-92 over JDBC\/ODBC<\/td>\n MongoDB Query API and aggregation pipeline; SQL is read-only and Atlas-only<\/td>\n<\/tr>\n \n Time series functions<\/td>\n Built-in time-weighted average, time-bucket aggregation, interpolated sampling<\/td>\n $setWindowFields<\/code>, $densify<\/code>, $fill<\/code>, $dateTrunc<\/code> in the aggregation pipeline<\/td>\n<\/tr>\n\n Updates to measurements<\/td>\n Full.<\/strong> Standard row inserts, updates, and deletes<\/td>\n Restricted.<\/strong> Updates can only match on and modify the metaField; no upserts<\/td>\n<\/tr>\n \n Writes in transactions<\/td>\n Supported<\/td>\n No.<\/strong> Time series collections cannot be written to inside a transaction; reads are supported<\/td>\n<\/tr>\n \n Horizontal scale-out (free edition)<\/td>\n No.<\/strong> Community Edition is single-node; multi-node clustering is in the commercial Advanced Edition<\/td>\n Yes.<\/strong> Replica sets and sharding are included in Community Server<\/td>\n<\/tr>\n \n High availability (free edition)<\/td>\n No.<\/strong> Clustering and failover are Advanced Edition features<\/td>\n Yes.<\/strong> Replica sets provide HA in the free edition<\/td>\n<\/tr>\n \n Expiry (TTL)<\/td>\n Yes, via expiration settings on the container<\/td>\n Yes, via expireAfterSeconds<\/code><\/td>\n<\/tr>\n\n Secondary indexes<\/td>\n Yes, on container columns<\/td>\n Yes, on any field since 6.0; compound metaField and timeField index created automatically<\/td>\n<\/tr>\n \n Geospatial<\/td>\n Native GEOMETRY type with spatial index and WKT, via the NoSQL interface<\/td>\n GeoJSON with 2dsphere indexing, well established across the product<\/td>\n<\/tr>\n \n License<\/td>\n Server: AGPL v3 · Clients: Apache 2.0<\/td>\n SSPL for the server; drivers under Apache 2.0<\/td>\n<\/tr>\n \n Ecosystem<\/td>\n GridDB clients (Java, Python, C, Go, Node.js, Ruby, PHP, Perl), Kafka Connector, Grafana, Fluentd, Telegraf, MQTT, Node-RED, Apache Arrow<\/td>\n Very large general-purpose ecosystem: official drivers for nearly every language, Atlas, Compass, BI Connector, Kafka Connector<\/td>\n<\/tr>\n \n Best for<\/td>\n SQL-based analytics on high-frequency IoT and sensor data, on-premises or at the edge<\/td>\n Applications where time series is one workload among several and the schema varies per document<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Architecture: Purpose-Built vs General-Purpose<\/h2>\n
Data Model: Key-Container vs Time Series Collections<\/h2>\n
TIMESTAMP<\/code> 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.\n<\/p>\ntimeField<\/code>, an optional metaField<\/code> identifying the source, and any number of measurement fields. The schema is flexible, so documents in the same collection can carry different fields entirely.\n<\/p>\ndb.createCollection("sensors", {\r\n timeseries: {\r\n timeField: "timestamp",\r\n metaField: "sensorId",\r\n granularity: "seconds"\r\n },\r\n expireAfterSeconds: 2592000 \/\/ auto-remove data after 30 days\r\n})<\/code><\/pre>\n<\/div>\nCREATE TABLE sensors (\r\n ts TIMESTAMP PRIMARY KEY,\r\n value DOUBLE\r\n) USING TIMESERIES\r\nWITH (expiration_type='ROW', expiration_time=30, expiration_time_unit='DAY');<\/code><\/pre>\n<\/div>\nQuery Interfaces: SQL vs Aggregation Pipeline<\/h2>\n
SELECT<\/code>, JOIN<\/code>, GROUP BY<\/code>, and window queries without learning anything proprietary. The often-repeated claim that GridDB cannot do JOINs applies to TQL, not to the SQL interface.\n<\/p>\n$setWindowFields<\/code> gives you window functions such as moving averages and rank. $densify<\/code> fills in missing time points and $fill<\/code> populates their values by interpolation or carry-forward. $dateTrunc<\/code> handles time bucketing for downsampling.\n<\/p>\nThe Update Restriction<\/h2>\n
metaField<\/code> value and can modify only the metaField<\/code> value. Your update document can contain only update operator expressions, updates must be multi-document (multi: true<\/code> or updateMany()<\/code>), and upsert: true<\/code> is not allowed. Deletes are supported and follow similar matching rules.\n<\/p>\nScalability: Where the Free Editions Differ<\/h2>\n
metaField<\/code> in the shard key so that data from the same source stays co-located. A few constraints apply: shard keys containing the timeField<\/code> 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.\n<\/p>\nLicensing<\/h2>\n
Performance<\/h2>\n
Ecosystem and Operations<\/h2>\n
When to Choose Which<\/h2>\n
\n
\n
FAQ<\/h2>\n
Does MongoDB support SQL for time series data?<\/h3>\n
Can I update a measurement value in a MongoDB time series collection?<\/h3>\n
metaField<\/code>, upserts are not allowed, and writes cannot occur inside a transaction. Correcting a measurement value generally means deleting and reinserting the document.\n<\/p>\nCan GridDB Community Edition run as a cluster?<\/h3>\n
Can MongoDB Community Server run as a cluster?<\/h3>\n
Is MongoDB open source?<\/h3>\n
Do MongoDB time series collections support TTL and secondary indexes?<\/h3>\n
expireAfterSeconds<\/code>, 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.\n<\/p>\nWhich is faster?<\/h3>\n