In-memory databases are more resilient to attack.

In-memory databases are, by their nature, more resilient to attack than persistent databases.

In-memory database are stored, of course, in memory. That can be local memory (e.g. memory that was acquired by malloc() in the C language or the new operator in C++), or in shared memory (e.g. memory that was acquired by mmap() in UNIX-like operating systems).

In virtually all modern desktop and server operating systems, memory is protected. That means that a process that attempts to access memory outside of its own address space causes a segmentation fault and is terminated. Hence it is very difficult for a malevolent process to gain access to a database that was allocated via malloc()/new.

Shared memory is a bit more complicated. If the shared memory is ‘anonymous’, then it is not backed by a file and there is no way for a malevolent process to open a non-existent file. If the shared memory is backed by a file, then suitable file and directory permissions can control what users and/or groups can access it. That said, a malevolent process that gains ‘root’ access would be unimpeded by such permission settings.

If a malevolent process is somehow able to gain access to an in-memory database, it still has to understand the format to make sense of it. Here, proprietary systems have an advantage over open source systems. Obviously, with open source anyone technically competent can figure out the database format.

The next layer of protection is encryption. Even if a malevolent process doesn’t understand the database format, it can simply scan the memory for recognizable patterns like email addresses and social security numbers. However, if sensitive information is encrypted, as it should be, with strong encryption like AES-256, it is virtually uncrackable.

Persistent databases are like shared-memory database that are backed by a file. If a malevolent process can read the file, and it’s not encrypted (has plain-text fields), then it’s vulnerable.