GridDB Community Edition: a time series database for IoT ingest, built from source or from an RPM

What GridDB is for, and who the README is written for

GridDB describes itself in the README as "Database for IoT with both NoSQL interface and SQL Interface." That sentence is the whole positioning. The repository is the server plus a Java client; the JDBC driver lives in a separate repository, griddb/jdbc, and there are separate client repositories for C, Python, Ruby, Go, Node.js, PHP, Perl and Rust. If you write Java, this repository is enough. If you write anything else, you are installing this server and then pulling a second repository for the bindings.

The intended user is someone running time series ingestion on Linux x64. The README states that operation was confirmed on Ubuntu 22.04 with gcc 11 and RockyLinux 9.4 with gcc 11. It does not claim Windows or macOS support anywhere, and the build instructions assume a Unix toolchain. That is a narrower target than most databases people compare it against.

The topics attached to the repository (time-series, iot, bigdata, newsql, nosql, sql) match the README's own framing. Nothing in the README suggests a general purpose OLTP database, and the sample programs are about rows with names, statuses, counts and binary payloads, which is the shape of device telemetry rather than a customer ledger.

Two interfaces over one store: NoSQL and SQL

The design point that separates GridDB from a plain key-value store is that the same server exposes a NoSQL interface and a SQL interface. The README links a Features Reference for the details, a TQL Reference for the NoSQL query language, and a SQL Reference for the SQL side. The JDBC driver is the route into SQL from Java.

What the README does not do is explain the storage model, the consistency guarantees, or how the two interfaces map onto the same data. Those answers are in the linked manuals, not in this repository's README. Anyone deciding between the two interfaces should read the TQL and SQL references before writing application code, because the query surface differs and the choice is not trivially reversible once queries are written.

The client list is the other half of the architecture. There is one server, and a fan of client libraries maintained as separate repositories. That is a normal arrangement for a database with a C core, but it means version compatibility between server and client is something you manage yourself. The README does not document a compatibility matrix.

Installing GridDB from an RPM or DEB package

The package path is the shorter one. The README says that installing the package creates a gsadm OS user, and that operating commands should be run as that user. It also says you do not need to set the GS_HOME and GS_LOG environment variables in this mode, which is the main practical difference from a source build.

On CentOS or RockyLinux the install is an rpm invocation, and on Ubuntu it is dpkg:

# CentOS/RockyLinux
sudo rpm -ivh griddb-X.X.X-linux.x86_64.rpm

# Ubuntu
sudo dpkg -i griddb_X.X.X_amd64.deb

X.X.X is the GridDB version. The README warns that if an old version is installed you should uninstall it and remove conf/ and data/ under /var/lib/gridstore first, so this is not an in-place upgrade. That warning is the closest the README comes to an upgrade procedure, and it tells you the upgrade is destructive to configuration and data unless you back them up.

After install, the README says the default configuration is for local connection only, and that you should copy the multicast configuration into place before starting:

[gsadm]$ cp /usr/griddb-X.X.X/conf_multicast/* conf/.

Then set an admin password, edit the cluster name in conf/gs_cluster.json, start the node and join the cluster:

[gsadm]$ gs_passwd admin
[gsadm]$ vi conf/gs_cluster.json
[gsadm]$ gs_startnode
[gsadm]$ gs_joincluster -c your_clustername -u admin/your_password

The README shows the clusterName line in gs_cluster.json commented out, with the instruction to enter your own cluster name. If you skip that edit, the join command has nothing to match against. The cluster name appears in the join command as a positional argument, so the value in the file and the value on the command line have to agree.

Running the Java sample against a running node

The README's sample is Sample1.java, shipped under the package's docs/sample/program directory. It is the fastest way to confirm that a node is reachable and that the Java client works. The classpath points at the installed jar:

export CLASSPATH=${CLASSPATH}:/usr/share/java/gridstore.jar
mkdir gsSample
cp /usr/griddb-X.X.X/docs/sample/program/Sample1.java gsSample/.
javac gsSample/Sample1.java
java gsSample/Sample1 239.0.0.1 31999 your_clustername admin your_password

The five arguments are the multicast address, the port, the cluster name, the user and the password. The README shows the expected output as a Person line with a name, a status, a count and a lob array of byte values. If you see that line, the server, cluster join and client are all working.

Stopping is two commands, and the order matters because the cluster is stopped before the node:

[gsadm]$ gs_stopcluster -u admin/your_password
[gsadm]$ gs_stopnode -u admin/your_password

For a source build the same sequence applies, but you export GS_HOME and GS_LOG yourself and add $GS_HOME/bin to PATH before running gs_passwd, gs_startnode and gs_joincluster. The README gives the build as bootstrap.sh, then configure, then make, with Python3 and tcl required in advance. The tcl note is easy to miss: it is listed as a prerequisite before the build commands, and the README gives yum install tcl.x86_64 as the example.

Where GridDB Community Edition is the wrong tool

The README documents no rollback procedure for a version upgrade. It says to uninstall the old version and remove conf/ and data/ under /var/lib/gridstore. There is no mention of a migration tool, a schema version check, or a supported downgrade path in the README. If your deployment cannot tolerate rebuilding configuration and reloading data on every version change, that is a real constraint, not a documentation gap you can work around by reading harder.

Platform support is the second boundary. The README says operation was confirmed on Linux x64 with the two distributions named above. There is no Windows or macOS claim, and no container image is offered in this repository. The sample directory contains sample/docker/, but the README does not document a supported Docker workflow, so treat that as an example rather than a distribution channel.

The licence is the third thing to check before you commit. The repository carries GNU-AGPL-3.0.txt, and the licence field for the project is AGPL-3.0. There is also an EULA for GridDB Community Edition and a separate LICENSE-java_client file, which suggests the Java client is not under the same terms as the server. That distinction matters if you ship the client inside a product. Reading the two licence files is the only way to know which applies to what, and the README does not summarise the split.

InfluxDB as the other obvious starting point

The comparison people search for is GridDB against InfluxDB, and the difference that matters is visible in this repository's structure rather than in any benchmark. GridDB ships a SQL interface in addition to its NoSQL interface, with a JDBC driver in a separate repository and a SQL Reference manual. InfluxDB's query surface is built around its own query languages rather than SQL, so a team with existing SQL knowledge and JDBC tooling has a shorter path with GridDB.

The second difference is deployment shape. GridDB here is a C++ server you install from an RPM or DEB or compile yourself, with a gsadm OS user created at package install time and a cluster join step before the node serves traffic. That is a self-managed, cluster-oriented install. InfluxDB has a broader set of distribution options, including managed offerings, which the GridDB README does not mention at all.

The third difference is the client surface. GridDB maintains separate client repositories for C, Python, Ruby, Go, Node.js, PHP, Perl and Rust, plus JDBC for SQL. That is wide coverage, but each is a separate repository with its own release cadence, and the README offers no compatibility matrix tying client versions to server versions. If you are on Python, you are depending on griddb/python_client matching the server you installed.

Maintenance, releases and the upgrade cost

The repository is not archived. The last push was on 2026-03-19. The most recent release listed is v5.9.0 from 2026-02-18, following v5.8.0 in 2025-06-03 and v5.7.0 in 2024-11-13. Those three dates are roughly seven to eight months apart, so the release rhythm visible in the README is a couple of releases a year rather than a continuous stream.

The release notes for each major version are in the docs/ directory, and the README links them from V3.0 through V5.9. That is a long documented history, and it is the first place to look when you need to know what changed between the version you run and the one you are considering. The README does not link a changelog beyond the per-version release notes.

Upgrade cost, as far as the README shows, is high relative to a typical database. The package instructions say to uninstall the old version and remove conf/ and data/. Nothing in the README describes an online upgrade, a rolling restart, or a data directory format that survives a version change. Plan for a maintenance window and a data reload, and keep your configuration files under version control outside /var/lib/gridstore so you can restore them after the removal step.

On licensing, the repository contains GNU-AGPL-3.0.txt, an EULA for GridDB Community Edition, and LICENSE-java_client. AGPL-3.0 carries network copyleft obligations that differ from permissive licences, and the presence of a separate client licence means the terms are not uniform across the repository. This is not legal advice; if you are embedding the server or the Java client in something you distribute or expose over a network, have someone read those three files.

Editorial conclusion

GridDB Community Edition is worth evaluating if you ingest time series data on Linux x64 and want a SQL interface alongside a NoSQL one without adopting a JVM-based store. It is the wrong choice if you need a managed cloud service, because the README describes only self-hosted source, RPM and DEB installs, and the repository contains no cloud deployment path. Before committing, verify three things: that your distribution matches the ones the README says were confirmed (Ubuntu 22.04 and RockyLinux 9.4), that the AGPL-3.0 licence on the server is acceptable for how you intend to distribute your own software, and that the Java client jar at /usr/share/java/gridstore.jar or the JDBC driver at griddb/jdbc covers the language you actually write in.

Frequently asked questions

Official sources

1. griddb/griddb on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases