Yeah, I have the problem, which is why I chose Jisp instead. Our database is a couple of gigs, so no go.

Your comparison with the umbrella and walking across the road is great, because that's essentially what they're saying. "If you don't think about a problem, it doesn't exist". Right.

If your objects don't fit in the memory, don't use Prevayler.

You'll be surprised to how few systems actually fit in this category.

We're about to release a new product based on Prevayler. It will be sold towards very large companies. According to our tests you can easily fit millions and millions of objects into the RAM of any fairly modern computer. (Of course all "content", video, sound, discussions and so on is kept on disk.)

"...indexes can't fit in main memory..." Hah! With Prevayler you don't need indexes. Our tests show that with millions and millions of objects the system is still faster than any system I've ever seen.

Wrapping you're head around Prevayler is a bit hard though. But, don't worry, you'll get used to it.

The above is a perfect example of exactly what I'm talking about.

Mate, I have my head wrapped around Prevayler. I've wrapped my head around it several times, and tied it up in a nice double-bow. I know precisely how it works, what it is capable of, what its strengths and weaknesses are. I am not an idiot, nor are the other people who are routinely dismissed on the Prevayler site when they try to point out that the product may not be the cancer-cure it's painted to be.

I have even publicly supported the idea of keeping your objects in RAM if you have the memory to do so - http://fishbowl.pastiche.org/archives/001221.html - like I said, Prevayler is a great solution for a certain class of problem. What I object to is the blinkered boosterism that seems to run alongside it.

"According to our tests, you can easily fit millions and millions of objects into the RAM of any fairly modern computer."

That's great, if you're the only application running on that computer. The moment you have to share resources with anyone else, you've got to start thinking difficult things like how to trade-off between memory usage and performance.

Oh, and in my day-job, I'm working on an application where the database is 5 gig before the server is even turned on for the first time. And we need to be running about ten of these databases to support the testers and the development team.

And even if you have a dedicated machine, you have to wonder what happens if you're providing some kind of service that gets really popular, really fast. Brad from Livejournal originally wrote the site to host him and a few friends. If he'd written it using Prevayler, it'd have fallen over the moment it got really popular, and today he wouldn't be running a website with half a million users.

These are all things you have to take into account when you're choosing a persistence solution. The Prevayler documentation pretty much ignores every real issue.

"Hah! With Prevayler you don't need indexes".

Rubbish. What do you think a HashMap is? Do you think the
Collection classes just work by magic? That's how OODBMS indexes work too.

And anyway, you're avoiding the point. With an OODBMS, the indexes have to fit in memory. With Prevayler, every object has to fit in memory. Which one has to worry more about RAM constraints? Why does the Prevayler documentation say that it has to worry about RAM _less_ than an OODBMS when it really needs to worry more?

Feh.

Charles,

No, I don't think you really get it.

Your argument is like so many of the banal "Java is slow" arguments to which people respond "Java is good for a certain class of problems, of course you're not going to write an operating system in Java..."

You can use the technological relativist argument but what you're ignoring is that Prevayler is fundamentally a much easier and more elegant technology to use than any database, relational or object. Prevayler gets rid of the impedance mismatch. This does wonders for productivity--it's possible to literally churn out complex business applications without wasting *tons* of time writing mapping logic or mapping file. Further Prevayler allows you to do _real_ OO programming on the server side, rather than using business objects that are little more than glorified structs.

The benefits of Prevayler are _real_ and _proven_. Any argument you make against Prevayler cannot be based on the silly notion that "since Prevayler doesn't work for me, it probably won't work for you." Instead you've got to provide a convincing argument that the cons of the technology outweigh its pros.

Anyways, my point is, try Prevayler :) I have feeling that you, as somebody who really appreciates elegant simplicity, will like it.

The only problem with prevayler is that it doesn't provide a good querying mechanism but there are people working on that...

- Bo

No, my point is that Prevayler is good for a certain class of problem but it is served very badly by its proponents, who belittle any attempt to point out the class of problems that it is not suited for.

Please point to anywhere I said that Prevayler is, in itself, a bad thing. I believe my exact words are: "For a certain class of program, it's a very useful persistence solution."

My point is that the uncritical evangelism on its website does it no good whatsoever.

A HashMap is not an index. It's a Map. You can use it to implement an index. Indeces are specifically useful when the values are located on disk because a disk access is an order of magnitude slower than a memory access.

With Prevayler you don't need indeces because all objects are located in memory and in all cases I've encountered so far it's just as fast to do a "full table scan".

If you have 5 gigs of data in your database you can probably not use Prevayler at the moment. But if you wait maybe one or two years that kind of RAM will probably be normal.
You might try to use an OS/390 too, where there isn't a fundamental difference between RAM and secondary storage.

The Prevayler people can be a little over zealous though perhaps not much more than any of the language zealots.

My point was only that the Prevalent Hypothesis shouldn't be construed as a flaw of the technology in itself. It's fundamentally understood that every technology has its context and makes its assumptions (the way Java makes assumptions that C++ doesn't) and you can't argue against a context. This is even more significant since I there obviously a large class of business apps might be best served by a prevalent system.

- Bo

A Hashmap is an index. It indexes pointers to objects into buckets based on their hashcode value. The difference between a memory-based index and a disk-based index lies in the algorithms used, and in their performance. They're still both indexes.

Anyway, here's a list I'd like to see on the Prevayler site:

Advantages of Prevayler:

1) Very, very fast.

2) You can fit a great many more objects into memory than you think you can.

3) You can have whatever object model you like, you don't need to pervert it so it'll map more efficiently to the relational model

4) Queries are essentially free, so long as you've organised your data to cater to them (and don't mind playing slightly fast and loose with concurrency. Otherwise they're only _almost_ free).

5) No O/R mapping or descriptors necessary.

6) Very easy to program for.

7) When the standard query language comes, it will probably still search over in-memory objects faster than in-memory-indexed disk-bound systems.

Disadvantages:

1) Even on a dedicated system, it can not cost-effectively deal with more than a few gigabytes of data (this is a huge amount of data).

2) Does not play well on personal computers or shared systems, where being frugal with resources is necessary.

3) It is harder to cater for exponential growth (common with internet applications) or usage spikes on a memory-bound system than on a disk-bound system.

4) Access to the data is limited to people who speak the host language. (i.e. you can't write a quick-and-dirty Perl script to graph your data)

5) No declarative security.

6) Concurrent access must be manually programmed for, either through very coarse-grained locks, or single-threaded access.

7) (Following on from 6) If you go for locks, there's no deadlock detection, which could be quite dangerous.

8) An arbitrary query language is coming "Real Soon Now". Until then, you can only access the data in ways that the programmers originally intended.

9) Either you must use up twice as much memory as you need in order to run a second copy of your data, or you must wear the time it takes to periodically freeze in order to snapshot and save your data (in the order of seconds for millions of objects, minutes for tens of millions).

10) ACID-ity, locking and transactional isolation are not supported natively, they must be implemented by the developer. This makes transactions that involve systems external to the Prevayler data a problem.

Non-issues:

1) Schema migration can be a bastard for either O/R or pure OO systems.

Charles, it's nice to see some concrete complaints instead of the endless dissections of the word "database". ;-)

Regarding (2), why won't it play well on those? There are lots of desktop applications that don't have much data.

Okay, Maps are indeces. You structure your data into an object model and there's little need to use indeces except how you would ordinary use indeces in your object model.

Some misunderstands though Charles:
"6) Concurrent access must be manually programmed for, either through very coarse-grained locks, or single-threaded access.

7) (Following on from 6) If you go for locks, there's no deadlock detection, which could be quite dangerous."

Actually, in the default Prevayler implementation all writes to the system are synchronized. One write at a time. So there's no threading issues at all. If you avoid hitting the disk or other I/O in your transaction (that's a big no no anyway), the scaleability is almost absurd (according to our tests). Since there's one lock only deadlock is impossible.

Anders:

It's less an absolute, more a change in assumptions.

When you have dedicated resources, the assumption is your application can grow to fill those resources, and where it is cost-effective to do so, your available resources can also be expanded.

When you have shared resources, you are expected to be a 'good citizen' and use as little as you can get away with. Rather than consume memory at will, you should profile in order to see where consuming more memory will provide a benefit to the user equivalent to the resources consumed.

As a concrete example: I run a wiki on my own server (about 1300 pages) so I don't care that all its pages are kept in memory (I don't use Prevayler, I just have it save a new serialized snapshot every time a page is saved. The size of the site, and ratio of reads to updates is such that this isn't a problem).

I run my weblog (about 1000 pages) on a shared host , and as I am expected to use the minimum necessary "expensive" resources such as memory and CPU cycles, I use MT, which mostly uses static pages, and puts dynamic data in Berkeley DB.

Many applications use even less data than this, but this is reaching the point where even Prevayler (with the necessity of the Command-based interface to modifying your data) is overkill. For most desktop applications, for example, you don't need to persist every update, you just need to save your state in a big block every so often.

I just posted another concern about Prevayler yesterday at http://blogs.browsermedia.com/patrick/index.do?date=20030410#111621. The short version is that Databases are far more well understood paradigm and you give all that up to use something like Prevayler.

Charles,

Your wiki sounds like a good example of an application where prevayler would be usable. In other words, the Prevalent Hypothesis holds for it, while it doesn't for the weblog example.
I don't understand why you found the the Prevalent Hypothesis so provocative?

I enjoy reading your blog but I think you've seriosuly mischaracterized Prevayler "marketing". The stated requirement has always been that your app must fit in memory. There are obviously a ton of applications that don't meet this requirement, and those applications should not use an all-in-ram solution like Prevayler.

I think the only people who suggest that Prevayler has been oversold are the people who never liked the idea in the first place.

If you have too much data for memory, split it across multiple JVMs. That's what Coherence distributed caches do. Some of our customers have many (many) gigabytes of data in in-memory Coherence caches, they just have to run more JVMs on more servers if they want to keep it in memory. Peace.

Nice one. Well done for not losing your temper!

http://www.darrenhobbs.com/archives/000422.html

Anders:

A hypothesis is a claim that needs to be backed up by data.
The way that Klaus used it on the PrevaylerIsNotADatabase page makes it more "the Dangerous Prevalent Assumption".

He specifically stated that as once you adopt the Prevalent Hypothesis, you _no longer need to worry about RAM_, which is a blatant untruth. The reality is, once you adopt the Prevalent Hypothesis, you commit yourself to having available RAM be one of the primary concerns of your application.

That's what I mean by the gap between hype and reality.

Steve:

You misunderstand me. I like the _idea_ of Prevayler, and it pains me to see it being mis-marketed so badly that even I, an avowed supporter of "only reluctantly use an RDBMS after you've considered all the alternatives" (once again, see http://fishbowl.pastiche.org/archives/001221.html ), am put off using it by the hyperbole surrounding it.

Charles,

A hypothesis is not a claim. (Merriam-Webster instead suggests "an assumption or concession made for the sake of argument").

Your kind of twisting Klaus' words here. Clearly you don't need to worry about RAM if the hypothesis is true for your application, since the hypothesis *is* that you don't need to worry about RAM. If the hypothesis doesn't hold, then you can't use Prevayler. Where's the gap?

Anders, I don't quite understand how I am twisting anything.

Klaus stated unambiguously that RAM is not a concern of a Prevalent application, because of the Prevalent hypothesis. I consider this dissembling, because the Prevalent hypothesis assumes an intimate concern with the availability of RAM.

This happens throughout the site. People pointing out shortcomings in Prevayler are told that these are not shortcomings, because they are things that someone using a Prevalent application (who has bought into the Prevalent Hypothesis) will _by_ _definition_ not be worrying about.

If the hypothesis doesn't hold, you can't use Prevayler. How do you discover the hypothesis doesn't hold? By worrying about RAM limitations. Why is RAM not a concern? Because we are concerned about RAM, we're just calling it something else.

It's hand-waving.

Having tracked Prevayler since its inceptions,
I would only comment on the "non-design" aspects.

1. Prevayler makes economic sense. It is *cheap* to use, considering the costs for developers which to "hybernate" or "ejb" around your app./database server for months, burried in XML descriptors (yes, I know about XDoclet) only to produce underperforming and bloated "enterprise" system. I do not even include DBA, QA and client-support personnel, nor software licenses costs! You can use a fraction of the saved money to beef up the server RAM to 4GB and soon, when the 64-bit CPUs become common, more than 4GB.

Prevayler is by far simpler and leads to much more productive development (just like AOP does!)

2. Prevayler is not suitable for EVERY project.
As mentioned by others, if you develop Java apps
for PDAs , cell-phones, you should consider something else. However, it is perfect for hosted web applications. Think over this: can you sell the computer as part of the project? How much RAM memory your application will use?

3. Prevayler is a tough sell in corporate America, where there are lots of entrenched old-timers IT managers.
Use it under the hood, if you can and when you do not have the freedom to select technologies. For small start-ups, Prevayler can provide competitive advantage over "standard" solutions.

3. The aggresive (and perhaps arrogant) style of posting by Klaus and others is deliberate.
This is because many of us need a healthy kick
to wake up and start using their brains. Just do not take it personally, accept personalities as they are, make your math and be cold-blooded professional!

Prevayler is not meant to co-exists, but, to displace "database servers", "application servers", "caching", "transactions", etc.,
things, so deeply rooted in our brains.

4. Prevayler does stimulate you to be an OO/AOP Java developer. You have to think for concurrent access, indexed collections, etc. This is quite in contrast to the VB-level stupification that the industry tries to enforce: "Do not think about multi-threading, caches, transactions - our wonderful server will do most often half of what you need, butif your manager is unhappy with the performance, make him watch our commercials on the TV. Do not worry!"

Hristo

Why would I want to use Prevayler over something like HSQLDB running only in-memory? At least with HSQL I've got:

A SQL query mechanism
Some hope of pretty easily converting to a full RDBMS if/when I need more data than I can hold in memory

Prevayler seems like an ok idea, but I don't see why I shouldn't use BOTH in-memory fast data access AND an RDBMS with a plan for growth, if need be?

Jason,
HSQLDB is OK-ish, neat and free SQL (embedded)engine. In fact, it pioneered some of the Prevayler tricks - only register UPDATE statements as the program goes, and apply them to the data file the next time it re-starts.
The main disadvantage of HSQLDB and JDBC is that it *damages* your object-oriented java code. Fundamentally, using alien code (SQL) in your java code does not scale, despite the numerous attempts to "wrap it", "isolate it" or confine it
with some design pattern. It is just a piece of non-java code that evades the checks of the java compiler and requires extra code to talk to normal java objects!(By the same token, the query language in EJB 2.x comes with the same problems).O/R tools go only half way - they still impose restriction on your object model or require bloated XML descriptor.
The SQL query abilities are over-hyped and give you false comfort. Accessing objects thru "reachability" (e.g. following pointers/references) is just as powerful as accessing objects via "querability".
Also, have you checked out S.O.D.A (http://www.odbms.org/soda/)?
When it comes to the performnace, JDBC can never
be as fast as direct object access, becausse, there is always the marshal/unmarshal JDBC protocol between your program and the data table, even when the later is fully in memory.

With Hibernate I can have basically any OO model I want and it's transparent if you design your data access well and use some kind of interceptors to set up and tear down for you. I agree it can't be as fast, but it can be fast ENOUGH, and doesn't limit my furure options.

I'm not sure you understand Prevayler well enough if you're making these statements about its disadvantages. They're all true some of the time, but most are not true all of the time.

==1) Even on a dedicated system, it can not cost-effectively deal with more than a few gigabytes of data (this is a huge amount of data).==

That depends on how you figure your costs and what you're comparing it with. As another person pointed out, EJB has enormous costs if you figure in all of the personnel and licensing overhead. And these are recurring rather than one-time costs. RAM can either be a recurring or a one-time cost depending on your application. If your data is growing so fast that you'll need to buy RAM regularly, don't use Prevayler. Otherwise, it's just a one-time or very infrequent cost (ie: when you would be replacing the server anyway).

==2) Does not play well on personal computers or shared systems, where being frugal with resources is necessary.==

Again, this depends on the application. We actually have a Prevayler application deployed here on a shared server. But our RAM needs are currently in the kilobyte range and are not expanding much at all, so we don't care.

As I see it, there is this gap between applications that are best served by storing data in files (single user, mostly productivity apps) and huge enterprise applications. These applications' data needs usually run in the hundreds of megabytes and occasionally in the gigabytes of data and they are usually multiuser. These are the perfect applications for Prevayler.

==3) It is harder to cater for exponential growth (common with internet applications) or usage spikes on a memory-bound system than on a disk-bound system.==

Applications that have exponential growth in their storage needs shouldn't use Prevayler.

On the other hand, Prevayler is ideal for applications where the amount of data is relatively constant but there can be exponential growth in utilization because it largely eliminates the disk I/O bottleneck. Result: you can serve many more concurrent users on the same hardware.

==4) Access to the data is limited to people who speak the host language. (i.e. you can't write a quick-and-dirty Perl script to graph your data)==

Prevayler isn't a server. It's just a Java-based persistence library. You either embed it in a server, for example inside Tomcat, or write your own server based on it. (Recently I committed an example server to Prevayler CVS, but you don't have to use it if you don't want to.)

With this in mind, there's nothing keeping you from building multi-language access into your Prevayler server. Want SOAP access? No problem. Want CORBA access? Again, no problem. Want to just use XML documents over HTTP? Go for it.

==5) No declarative security.==

Yes and no. You get the exact same security as Java gives you: public, private, protected, package. This is certainly declarative, but doesn't go as far as most RDBMSs provide.

However, if you write your own server, you get to define security however you like. I usually have my objects pass an authentication token to the server when they make a request. The server has a declarative-style security framework that the user's requests are automatically authenticated against. It's trivially easy to use and fully automatic now that its written.

But of course I had to write this myself for my server. Remember, Prevayler isn't a server, it's *just* a persistence library. But it frees you to write your own server to exactly your specifications. Or you can use/modify the one I committed to Prevayler CVS.

==6) Concurrent access must be manually programmed for, either through very coarse-grained locks, or single-threaded access.==

um--you just use the "synchronized" keyword...

And since Prevayler already sequences writes for you, this is a lot easier than programming concurrent applications in the general case.

==7) (Following on from 6) If you go for locks, there's no deadlock detection, which could be quite dangerous.==

Following from Prevayler automatically sequencing all writes, I have never had a practical case where this has ever been an issue.

Here's the key: You *just* have to make sure that your reads are consistent, which simply means that reads just wait for a write to complete its critical section before executing. That's it. It's the simplest concurrent programming I've ever done because Prevayler's automatic sequencing of writes handles the hard cases for you.

==8) An arbitrary query language is coming "Real Soon Now". Until then, you can only access the data in ways that the programmers originally intended.==

Assuming that the programmers provided the standard JavaBean-style accessor methods for all data (possibly wrapped or AOP'd into a security framework), this is a non-issue.

It's true that properly structuring your data requires some thought on the programmer's part up front. However, relational databases suffer exactly the same problem: if the right tables don't have the right foreign keys, you have to involve more tables in a query than should be necessary, resulting in slower performence than should be required. Similarly, if the DBA before you denormalized some relation in order to increase performance for some set of queries, you could wind up needing to write some inefficient query code indeed in order to get the data you need.

The only difference between Prevayler and SQL databases here is that you lose the marshalling layer, SQL compilation, etc. between your business objects and your query code. This makes your code much simpler to understand and work with and gives you the speed of RAM rather than the speed of the disk.

==9) Either you must use up twice as much memory as you need in order to run a second copy of your data, or you must wear the time it takes to periodically freeze in order to snapshot and save your data (in the order of seconds for millions of objects, minutes for tens of millions).==

I think this is a pretty fair description of the tradeoff you have to make when you're deciding how to handle snapshotting your data.

There are a couple of other variables too, like if the data doesn't change very much (it's mostly an information retrieval system), you might be able to get away with snapshotting only at 4:00 AM on Saturday morning when nobody is working anyway. Then you just document that the system is down for 10 minutes starting at 4:00 AM every Saturday morning or whatever.

But you're right that you have to take this into account when you're designing the system.

On the other hand, when you take into account the cost of a full-time DBA and the licensing costs for high-end application servers, you may decide you're easily able to afford a second server so that the system experiences zero downtime during the snapshot operation.

==10) ACID-ity, locking and transactional isolation are not supported natively, they must be implemented by the developer. This makes transactions that involve systems external to the Prevayler data a problem.==

This is the biggest confusion I've seen about Prevayler. Since Prevayler sequences all writes and applies them atomically, ACID is supported without the programmer even thinking about it.

Similarly, as I said above, the only locking and transactional isolation issue you have to worry about are making sure that your reads are consistent, something easily handled using Java's "synchronized" keyword.

Regarding transactions involving systems external to the Prevayler data, you're right that this requires some thought. Basically, you have to make sure that the external actors are only notified of changes the first time a transaction is executed and not when the log is being replayed.

One way to do this (and my socket server provides a framework to handle this for you automatically) is to use the observer pattern. Basically, all external actors connect to your Prevelant system as an observer, and perform their actions based on notifications that events have occurred. Since nobody can be connected to your prevalent system during command log replay, this automatically ensures that the external actors are notified only when the commands (or Transactions as they're now called) are initially executed.

==Non-issues:

1) Schema migration can be a bastard for either O/R or pure OO systems.==

I actually would have put this at the top of the list of drawbacks. There currently isn't a good solution to this problem, and as I see it, it's mostly the fault of the Java runtime. The basic problem is that unlike Smalltalk, Java was not designed to be evolved from within itself while it is running. So you run into a whole bunch of headaches here.

There are solutions, but none of them are elegant and the ones that would wind up being most transparent to the developer are so complicated that nobody has implemented them yet.

But there are ways to manage this and I'd encourage people to read the Prevayler wiki (topic="SchemaEvolution") and mailing list archives to see what has been done here.

What sort of fear and anger cause such a little misunderstanding to produce so much garbage?

On the Prevayler site, anyone can read: "Prevayler does not worry about RAM limitations".

So, if you are going to use Prevayler and Prevayler itself doesn't worry about RAM, obviously YOU have to worry about having enough RAM.

Even if one is too stupid (or blinded) to conclude that, the Prevayler site will make sure there can be no mistake: "If you don't have enough RAM don't use Prevayler."

But instead, Charles, blinded by some sort of anger or fear or something, chooses to read, on his own accord: "Prevayler users need not worry about RAM limitations." :P

It amuses me that even Rickard (blinded by what?) falls for that rubish.

Charles, you are either an idiot or blinded by some sort of anger to oversee such a childish mistake.

"I am not an idiot"

Hope not. If you are, happy Prevayler-zealot-hunting to you. :)

----

A little curiosity: Charles Miller is also the name of the guy who brought football (soccer) to Brazil in the late 19th century.

Klaus: Your comment more than proves my point.

The way you phrase it, "Application X does not need to worry about RAM" is a meaningless non-statement, that is true of every single application ever written: "Application X assumes there is sufficient RAM in which to run Application X".

Thankyou for your input, have a nice day.

Charles.

You wrote:

"To save you following the link, the Prevalent Hypothesis is (direct quote) 'That there is enough RAM to hold all business objects in your system.' That's right. Users of Prevayler don't have to worry about there being enough RAM because... we assume there will always be enough RAM!"

No we don't. You're wrong. WE DO NOT "assume there will always be enough RAM!"

If there isn't enough RAM we either buy more RAM (that's worrying) or we simply don't use Prevayler. The site makes that perfectly clear and you know it.

That's it. You ARE wrong and you know it.

I resent your accusing me of being "arrogant" just for proving people like you wrong. :(

The biggest flaw with Prevayler is the lack of rollback facility. If a bug somehow gets into a production system that causes, say, a NullPointerException, this will leave the data in an inconsistent state. At least with proper ACID transactions, this incosistent data will never bet written to the database, but this is very possible with Prevayler.

Following up on Charles' post from way up:

>

Of course this is not quite true. In a prevalent system if you change your objects you DO have to migrate your snapshots and possibly your command logs. This can be non-trivial.

WORSE, what happens if your B-O logic changes, and it will. To guarantee "determinism" (one of the prevayler assumptions) this must not happen if you want to reload command logs. You must have a snapshot before you deploy logic changes if you want to abide by the determinism/reproduceable requirement.

OOps, the quote didn't post it was:

"Non-issues:

1) Schema migration can be a bastard for either O/R or pure OO systems."

If you just want to use Prevayler for quick and dirty persistence then that's fine. I'm sure it works well for that. And yes it does get rid of the OO/RDMBS impedance mismatch. But there is a cost with using it and that comes with the loss of data integrity you have by not being able to specify declarative integrity constraints like you can with SQL DBMSs. You have to code this into your classes which is much more expensive and harder to maintain in the long run.

If you care about data integrity and ad hoc manipulation then dont use Prevayler. If you dont then it's probably OK to use it.

And getting back to the OO/RDBMS impedance mismatch, has anyone stopped to think that the OO approach of storing all your data as object graphs might not be the best approach? It basically creates the same problems people had with hierachical databases in the 60s and 70s. The sort of problems that the relational data model was designed to overcome.

I am more and more inclined to the idea that a truly relational DBMS together with a procedural/functional language would create a much more productive application development toolset than OO language + persistence layer. If that's the case then Prevayler is fixing the wrong part of the problem.

Dude, you obviously weren't paying attention. The Prevayler people SAYS NOWHERE ON THEIR SITE that you will always have enough RAM to hold all your business objects. In fact, your claim that they do is so outrageously dishonest, that you should immediately post a retraction and an apology. What they DO say is that IF all your business objects fit in RAM then you can use Prevayler instead of a database. And if they don't, then you can't. That's it.

I remember doing some consulting work in a client, and seeing how happy their developers where because they where using hibernate, so now their RDBMS was only a backstore, they were doing pure OO, etc, etc...
Well, when I´ve looked at their code I saw a lot of IDs as attributes instead of object types. And they think they know OO...
A lot of the hype that comes with solutions like prevayler come from people who are SQL-impaired and that think they know OO.
Frankly, while the impedance problem exists, it can be resolved with a sound, well factored OO design and with the help of tools like Hibernate or toplink, provided you have a brain.
Hibernate is fast because it runs in memory. huh-huh. Give me lots of memory and I´ll grow my SGA large enough to make Oracle runs almost exclusevely in-memory.
And even Microsoft can work out a benchmark "proving" that SQL Server is faster than Oracle.
And after all, we will end up with the same problem we´ve got with ADABAS, it were fast, but try changing the schema, or try querying your data in a little different way it was designed :-)