One of the major benefits of encoding data as a JSON field is that you don not have to predefine what structure or shape that data will have. Further, the shape of the data can vary from one row to the next.

In the json-sessions example, the schema for the JSON column is defined by the Java objects themselves, on the fly, rather than having to define the structure using SQL ahead of time. If a new Java object, such as a new session type, is needed, you simply create the Java object, serialize it to JSON, and store it in VoltDB. This avoids the need to propagate a new catalog with DDL changes to the database.

On the flip-side, using a variable schema in the JSON column means that your application must be intelligent enough to understand the various structures that appear in that JSON column. Further, you must be sensitive to when indexes are needed, should query patterns change in your application along with the shape of the data. This may, for example, require you to add (or modify) indexes based on the existence of new fields that are now frequently queried.

Another point of note is the size limit for JSON values. In VoltDB, VARCHAR columns, in which JSON values are stored, are limited to 1MB, exactly 1024^2 bytes (1048576 bytes). In this way, JSON support lets you augment the existing relational model within VoltDB. It is not intended or appropriate as a replacement for pure blob-oriented document stores.