solidDB offers both disk-based tables (D-tables) and in-memory tables (M-tables).
From an application design perspective, D-tables and M-tables are very similar.
▪ Both table types provide full persistence of data unless specified otherwise.
▪ You can run the same types of queries on both table types.
▪ You can combine disk-based and in-memory tables in the same SQL query or transaction.
▪ Both table types can be used with indexes, triggers, stored procedures, and other common database objects.
▪ Both table types allow constraints, including primary key and foreign key constraints, although there are some limitations on foreign key constraints with non-persistent in-memory tables.
The main difference between M-tables and D-tables is performance. M-tables provide better performance; they can provide the same durability and recoverability as D-tables. For example, read operations on M-tables do not wait for disk access, even when the system is engaged in activities such as checkpointing and transaction logging.
With solidDB, you can decide which tables are in-memory tables and which tables are disk-based tables. For example, you can put heavily used tables in main memory so that they can be accessed more quickly. If you have enough memory, you can put all of your tables in main memory.
The main-memory engine that handles the M-tables and the disk-based engine that handles the storage of D-tables use different data storage architectures.
The in-memory engine is designed for maximum performance. Knowing that data is always stored in main-memory allows for use of data structures and data access methods that are designed to minimize the computational (CPU) cost of retrieving or updating database records.
The disk-based engine, however, can reduce disk access. Reduced disk access is achieved by data structures and access methods that trade disk access for additional computational processing. Therefore, an in-memory engine has the potential to outperform a disk-based engine even when the latter has cached all the data in the memory buffer pools because it consumes fewer processor cycles to access database records.