Is running postgresql in memory a good idea?

Recently we are working on migrate our software from general PC server to a kind of embedded system which use Disk on module (DOM) instead of hard disk drive.

My colleague insist that as DOM could only support about 1 million times of write operation, we should running our database entirely in a RAM disk and backup the dat开发者_JAVA百科abase to DOM.

There 3 ways to trigger the backup :

1. User trigger

2. Every 30 minutes

3. Every time when there is some add/update/delete operation in database

As we expecte that user will only modify the database when system is installed, I think maybe postgresql would not write that often.

But I don't know much about postgresql, I can not judge if it worth all this trouble and which approach is better.

What do you think about it?

The problem of wearing out SSDs can be alleviated by whatever firmware the SSD has. Sometimes those chipsets don't do it well, or leave the responsibility to someone else. In this case, you can use a filesystem designed to do wear levelling by itself. UBIFS or LogFS are suitable filesystems.

Assuming that the claim about the DOM write cycles is true, which I can't comment on, then this won't work very well. PostgreSQL assumes that it can write whatever it wants whenever it wants (even if no logical updates are happening), and you have no real chance of making it go along with the 3 triggers that you mention.

What you could do is have the entire thing run on a RAM disk and have some operating system process back this up atomically to permanent storage. This needs careful file system and kernel support. This could work if your device is on most of the time, but probably not so well if it's the sort of thing that you switch on and off like a TV, because the recovery times could be annoying.

Alternatives are using either a more embedded-like RDBMS such as SQLite, or using a storage system that can handle PostgreSQL, like the recent solid state drives, although some SSDs have bogus cache settings that might make them unsuitable for PostgreSQL.