I am looking for a RAM/memory based database, and these two seem to be interesting:

Do you have any other suggestions?

I need more than one executable to be able to access the DB concurrently.

Thank you.

More details:

I want to use a database as a high level communication channel among executables, instead of using the file system or shared memory.

File system pros: persistent storage (I do not care about it in this project).
File system cons: slow; hardware stress (both for hard disk and SSD).

Shared memory pros: speed.
Shared memory cons: data size; non persistent storage; low level access.

RAM Database pros: speed; high level, query-like access.
RAM Database cons: data size; non persistent storage (not a problem in my case).

  • 2
    What are your parameters? This is a very vague question.
    – user1240
    Jan 3 '12 at 3:14
  • 2
    What do you mean with "RAM/memory based database"? Do you want the DBMS to not be writing to disks at all so any OS failure or shutdown will result in total loss of data? Jan 3 '12 at 16:06
  • @RandolphWest: I still do not have a clear plan. I want to use a DB (instead of the file system and shared memory) to let executables communicate with each other.
    – Pietro
    Jan 3 '12 at 22:53
  • @ypercube: I want a DB that stores data in memory, and can optionally make periodic backups on hard disk. Data losses are not critical. It is used "just" as a high level communication channel among executables running on the same machine.
    – Pietro
    Jan 3 '12 at 23:01

I see two competing/conflicting requirements:

RAM/memory based database


more than one executable to be able to access the DB concurrently

They are competing/conflicting because modern operating systems normally enforce strict segregation for RAM allocated to specific processes (there are exceptions, but in the main this holds).

One option here is to copy your database to a RAM disk. That would allow separate apps to treat the database as if it were a file. The downside here is that the contents of a RAM disk won't survive a reboot of the host machine, and so you need a very robust system to keep your database saved to a real hard disk as well.

But really, if you want multiple apps sharing the same db, you're much better off using a database server. Enforcing safe, concurrent access is one of two main reasons databases exist as distinct entities from flat file stores (the other is efficient joins).

  • 1
    Well, shared memory allows more than one process to access the same memory area. But even without that, the DB could communicate with the other processes through memory. E.g., the data could be in the DB private memory segment, and the results of the queries could be sent through message queues.
    – Pietro
    Jan 3 '12 at 23:42
  • I used a RAM disk. It seems to be the most transparent and portable solution; the OS is in charge of everything...
    – Pietro
    Sep 27 '12 at 9:27

SQLLite is single user (in practice) and embedded. That fails the "more than one executable to be able to access the DB concurrently" requirement.

Otherwise, all RDBMS are in memory once the data is loaded from disk so you can use any you want (SQL Server (not CE), MySQL, PostgreSQL, whatever).

  • I would like the hard disk not to be touched at all.
    – Pietro
    Jan 3 '12 at 23:27
  • The fact that SQLite is single user could still allow it to interface with multiple processes owned by the same user, couldn't it?
    – Pietro
    Jan 3 '12 at 23:29
  • I checked (link), and yes, multiple processes can concurrently access the same SQLite database.
    – Pietro
    Jan 5 '12 at 23:36

Apache Derby or JavaDB may be worth a look too.

SQLite is pretty awesome provided you can live with the fact that only one user/process can write to the database at a time. Many processes/users can in fact read data and access the DB at the same time however (as mentioned by the SQLite FAQs).


Not sure what exactly you mean with "RAM/memory based database" but you can have a look at the Memory storage engine in MySQL.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.