McObject recently published a white paper, “Will the Real IMDS Please Stand Up?” The technical explains how to tell the difference between real and imitation in-memory database systems, and explains why it matters. The free report helps developers determine if they will obtain the IMDS benefits of fast performance and superior database efficiency from specific vendors and products often described as (or purporting to be) in memory database systems.
In-memory database systems (IMDSs) have changed the software landscape, enabling “smarter” real-time applications and sparking mergers and acquisitions involving the largest technology companies. But these days, the database sector teems with products purporting to be IMDSs. The problem is, most of them aren’t. The majority of products promoted as in-memory databases are merely old-style (on-disk) DBMSs, wearing a thin coat of IMDS paint.
IMDSs provide the features of traditional database management systems (DBMSs) — including transactions, multi-user concurrency control, and high level data definition and querying languages — but with a key difference: in-memory databases store records in main memory, eliminating disk storage and related overhead. This enables IMDSs to offer faster performance as well as a more streamlined design and smaller code size.
The popularity of IMDSs has caused products to falsely claim to be in-memory database systems. Understanding the distinction is critical for potential designers whose problem domain is best served by the technology. The differences can affect the hardware requirements (and therefore total cost of ownership), performance, time-to-revenue, and ultimately the success or failure of a solution.
Distinguishing between real and fake IMDSs often means examining the key areas of origins and wholeness. The origins of a purported IMDS can point to whether the product is truly optimized for in-memory use, and reveal whether performance-sapping “artifacts” remain from its original design as an on-disk DBMS.