Jedox Database Files

Overview

The Jedox In-Memory DB is an OLAP system that holds data in RAM for fast query times while maintaining a persisted copy on the file system. Data is stored in the "data" directory, where each database is represented as a subdirectory.

Every Jedox installation includes at least two built-in databases — System and Config — which store system configuration metadata. User-created databases each contain their own set of files holding only information relevant to that database.

How persistence works

To prevent data loss from power failures or crashes, every change made in RAM is immediately written to a journal file on disk. A disk cache flush runs every second to ensure data is truly persisted, and a full commit of the journal files occurs every 5 minutes.

File types

The following file types make up a Jedox database:

File type Description
*.csv Contains the last saved database state. On save, data is committed from memory to these files.
*.bin Binary equivalent of *.csv files. Faster to load and save; smaller on disk.
*.sha1 Checksum files that validate binary storage integrity.
*.log Journal files containing all changes since the OLAP server was last started. Used for data recovery after an unexpected shutdown.
*.archive Cumulative log of all value and structural changes, including the username for each change. Useful for auditing; not suitable for database recovery.
*.old Backup files created when the server is configured to save data in binary format only (no-csv-save / no-csv-save-dim). Not required for OLAP functionality.
*.saved-TIMESTAMP Marker files that record the current saved state relative to all database and journal files. Must be included when transferring a database to another system.

Comma-separated values (.csv) files

The structure of a Jedox database is defined in a file named database-*.csv. This file specifies cubes, dimensions, elements, and their properties. The filename includes a UNIX timestamp — for example, database-1557741467210061.csv.

Each cube listed in the [CUBES] section of database-*.csv has its own corresponding CSV file, which defines the cube's structure and current saved values. Each cube also has a separate CSV file describing its rules, if any exist.

Note: if the configuration key dimension-file-format binary has been set, then database-*.csv will contain only dimensions, cubes, and their layout — not the full element data for each dimension. See Binary (.bin) files below for details.

The following is an excerpt from the Demo database showing entries in the [CUBES] section of database.csv:

0;"#_GROUP_CUBE_DATA";0;1;1;0;0;
1;"#_Months";3;2;3;0;0;
2;"#_GROUP_DIMENSION_DATA_Months";0;2;1;0;0;
3;"#_Years";5;4;3;0;0;
4;"#_GROUP_DIMENSION_DATA_Years";0;4;1;0;0;
5;"#_Regions";7;6;3;0;0;
6;"#_GROUP_DIMENSION_DATA_Regions";0;6;1;0;0;
7;"#_Datatypes";9;8;3;0;0;
8;"#_GROUP_DIMENSION_DATA_Datatypes";0;8;1;0;0;
9;"#_Measures";11;10;3;0;0;
10;"#_GROUP_DIMENSION_DATA_Measures";0;10;1;0;0;
11;"#_Products";13;12;3;0;0;
12;"#_GROUP_DIMENSION_DATA_Products";0;12;1;0;0;
13;"Sales";12;6;2;4;8;10;2;1;1;
14;"#_#_CUBE_";14;1;3;0;0;

Each entry corresponds to a separate CSV file. The table below describes the individual cubes:

Cube Description
0;"#_GROUP_CUBE_DATA";0;1;1;0;0; Contains dimension cubes and groups, and the access rights of each group to each cube.
1;"#_Months";3;2;3;0;0;
3;"#_Years";5;4;3;0;0;
5;"#_Regions";7;6;3;0;0;
7;"#_Datatypes";9;8;3;0;0;
9;"#_Measures";11;10;3;0;0;
11;"#_Products";13;12;3;0;0;		 Attribute cubes for each dimension (one per dimension).
2;"#_GROUP_DIMENSION_DATA_Months";0;2;1;0;0;
4;"#_GROUP_DIMENSION_DATA_Years";0;4;1;0;0;
6;"#_GROUP_DIMENSION_DATA_Regions";0;6;1;0;0;
8;"#_GROUP_DIMENSION_DATA_Datatypes";0;8;1;0;0;
10;"#_GROUP_DIMENSION_DATA_Measures";0;10;1;0;0;
12;"#_GROUP_DIMENSION_DATA_Products";0;12;1;0;0;		 User group and dimension cubes. Stores the element-level access rights for each user group.
13;"Sales";12;6;2;4;8;10;2;1;1; Data for the Sales cube.
14;"#_#_CUBE_";14;1;3;0;0; Attribute cube data for each cube dimension

Binary (.bin) files

Cube and dimension data can be stored in binary format instead of plain text. Binary files contain the same data as the corresponding CSV files but are typically smaller, resulting in faster load and save times — particularly noticeable at server startup and shutdown.

Cube data is stored in files named database_CUBE_*.bin. Dimension data is stored in files named database_DIM_*.bin.

Dimensions are not stored in binary format by default. To enable it, set the configuration key dimension-file-format binary. You can also configure the server to save data exclusively in binary format (skipping CSV output entirely), which further improves shutdown performance. Use the configuration key no-csv-save for cube data and no-csv-save-dim for dimension data.

Note: binary files are not transferable between Linux and Windows systems. CSV files do not have this restriction.

Cloud customers can request specific binary format configurations by contacting Jedox Support.

Checksum (*.sha1) files

Checksum files validate binary storage integrity by detecting errors caused by file system operations or disk failures. They are generated during the initial database load and stored in a checksums subdirectory within each database folder.

Generating checksums on first load may slow down that initial load, but subsequent loads will be faster as a result.

Checksum validation can be disabled with the configuration key no-checksum.

Log files

One or more log files (also called journal files) are created for each database. The number of files depends on journal file size limits and whether encryption is enabled. All changes to the OLAP Server are recorded in these files.

When the database is saved normally, the contents of the log files are copied to the corresponding *.archive files. If the OLAP Server shuts down unexpectedly, the log files are used to recover data on the next startup. This recovery process typically takes longer than a clean shutdown would have.

Important: log files include OLAP server version information, and the server will only process log files from a compatible version. If the version of a log file is significantly older than the current server version, the database may fail to load. To avoid this, either save all databases explicitly using the OLAP Server API, or restart the OLAP Server once before applying any Jedox updates.

Archive files

Archive files record all value and structural changes to a database, along with the username associated with each change. They are written continuously during server operation and represent a cumulative history of activity.

Archive files are useful for auditing and tracing changes, but they cannot be used to recover a corrupted database. For recovery purposes, rely on your standard backup procedures.

Archive files can be deleted periodically (after completing a backup) to manage disk space on the server.

Backup (*.old) files

These files are created when the server is configured to save data exclusively in binary format, using the no-csv-save or no-csv-save-dim configuration keys. In this case, the previous CSV files are renamed with a .old extension rather than deleted.

*.old files are not required for OLAP functionality and can be safely removed if disk space is a concern.

State marker (*.saved-TIMESTAMP) files

These files mark the current saved state of a database by recording the relationship between all database files and journal files at a given point in time. The filename includes a timestamp that identifies when the state was captured.

When transferring a database to another system, the *.saved-TIMESTAMP files must be copied along with all other database files. Omitting them will leave the database in an unloadable state on the destination system.

Updated August 31, 2026