Persistent in-memory tables

Persistent in-memory tables (M-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 M-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 (D-tables), data in persistent M-tables is copied to the hard disk during checkpoints.

Persistent M-tables can also be used with the solidDB HotStandby component; data in M-tables is copied to the secondary server from where it is available if the primary server fails.

The main difference between M-tables and D-tables is that M-tables are generally significantly faster. The following table highlights the differences between in-memory tables and disk-based tables.

Feature	Persistent M-tables	D-tables
Concurrency control	Always use pessimistic row-level concurrency control (locking)	Use optimistic (versioning) concurrency control by default
Checkpointing algorithm	Checkpointing does not block transaction access to tables. Thus, the predictability of response times is better with in-memory tables than with disk‑based tables.
Secondary indexes	Secondary indexes are never written to disk. They are maintained in-memory 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. All indexes are equally fast.	Primary index is significantly faster than secondary indexes.