Persistent in-memory tables persist indefinitely. Although client queries access the copy of the data in memory, the server stores the persistent in-memory tables on disk when it shuts down, and therefore the data is available each time that the server starts. Persistent in-memory tables also use transaction logging; if the server is shut down unexpectedly (for example, due to a power failure), the server has a record of the transactions that have occurred and can update the tables to ensure that they have all the data from all the committed transactions. As with disk-based tables, data in persistent in-memory tables is copied to the hard disk during checkpoints.

Persistent in-memory tables can also be used with the solidDB^® HotStandby component; data in in-memory tables is copied to the Secondary server from where it is available if the Primary server fails.

In most regards, in-memory tables are indistinguishable from disk-based tables, except that in-memory tables are generally significantly faster. The following sections highlight the differences between in-memory tables and disk-based tables.

In-memory tables always use pessimistic row-level concurrency control (locking). Disk-based tables use optimistic (versioning) concurrency control by default.

Depending on the type of table used, the error handling needs to take different error codes into account.BLOB

The checkpointing of in-memory tables is entirely different from the algorithm used on disk-based tables. Checkpointing in-memory tables does not block the transactions’ access to the tables in any way during the checkpoint. Thus, the predictability of response times is better with in-memory tables than with disk‑based tables.

With in-memory tables, the secondary indexes are never written to the disk. Instead, they are maintained in-memory only and rebuilt when the server is started. The impact of secondary indexes on the write performance of in-memory tables is significantly smaller than with disk-based tables. Moreover, all indexes of in-memory tables are equally fast whereas on disk-based tables, the primary key is significantly faster than the other indexes.