A colleague of mine at Zedak recently sent out an email directing our attention to Prevayler - a rediculously fast persistence layer for Plain Old Java Objects.

Boasting speeds 9000 times faster than Oracle and 3000 times faster than MySQL (when queried via JDBC), and licensed under the LGPL, one might ask why everyone hasn't already switched. The answer is simple, scary, and potentially complex: it stores the whole of your data model in RAM, so it's readily accessible at lightening speed. The concerns are obvious, and the answers simple.

Prevayler persists snapshots of the memory image to disk regularly (you can configure the schedule) to ensure long term persistence, and keeps a persistent log of issued commands in the event of a crash - similar to a journaling file system. The idea is that's its faster to write down what you asked for than to read the information you need; if you already know the answer, why go to the book, right?

The driving motivation behind Prevayler is that RAM is dirt cheap - much more so than physical storage. Of course it's not without its limitations; today's 64 bit processors can only handle 8 gigs of memory, and the vast majority of us are still on 32 bit hardware handling at most 4 gigs. Whereas one can store countless terrabytes of data on other mediums such as hard disks and DVDs - and lets face it, sometimes you just have more than 8 gigabytes of data; although for me and my friends Tom, Dick and Harry Web Developer, 8 gigs is a relatively unrealistic amount of information.

It's limitations and unrealistic applications are pretty well documented by Prevayler's authors though; they're even good enough sports as to post emails from uninterested traditional RDMBSers accusing them of being zealots.

Personally, I think it's a great idea. I saw mention of cross-language support on their site; perhaps I'll look into it for Blosxonomy caching. It'd be great if I could keep the Blosxom like file-system entries and use an in-memory DB like cache - my performance would sky rocket! It would also be a great segway into developing a full-on SQL based Blosxonomy entry locator.