When I tell people about db4o, I will always mention the following two things:
- It cuts your development time significantly (25% or more I would say). No more creating database schemas and making mapping files to map from your objects to your tables.
- It’s FAST! As in faster than that relational database you’re using right now.
Now a note on performance, take a look at these benchmark results. They compare a variety of common setups including Hibernate with MySQL and HSQLDB. db4o is clearly faster in most cases. And these benchmarks were done with db4o 5.2. db4o 5.5 is currently the latest and greatest and is generally substantially faster than 5.2. It will be interesting to see the Pole Position results with 5.5.
After seeing these benchmark results and knowing that db4o can save you a boatload of time (it’s also so pleasant to use), why would you not choose it?
3 comments:
"fast" has many meanings.
i love talking about db4o with my colleagues, how wonderful it is to work with, all the impedance mismatch non-issues, love comparing against our SQL work, but the one question i'm always fielded but can never start to answer is whether it will scale. we have very well known scaling characteristics for our SQL work, but no idea how db4o would hold up to a couple tens of millions of records. polepos is great, but third of a million records sometimes is, well, something to sneeze at. its hard enough to decypher just how db4o scales from the polepos tests, but to project that test into the domain of millions of objects is just not feasible.
(to me, it feels, &c) db4o has won the campaign war it has fought. you've convinced most everyone that looks that you are faster and easier to use. oreilly himself saw that. but thats not why people used sql in the first place. to start really swinging in the converts, i'd start illustrating just how many records db4o can support, and how well it can scale both out and up.
running with this thread, i'm not sure if its become an issue yet, but starting to discuss & dialog "scale out" would probably make a lot of people more comfortable as well, knowing that the notion is on the table.
i cannot wait until i can start using db4o at work. but even as a small risk taking dev shack, we still cant knuckle down and trust what appears to be a superior technology until we know it can do the heavy lifting our current database systems can.
ps, let bamboo get in some boo work again please. no, scratch that, make him get in some boo work. and congrads for being smart enough to start writing test cases in boo; they're simple concise and self documenting. and way to go for hiring the damned smartest people there are, you have an amazing crew.
Thanks for the comments rektide and I agree with you 100%. Scalability is always a concern when evaluating a database especially in a server based environment (web apps). Perhaps with some nudging, we could get more extensive tests into the pole position test suite. Shouldn't take much effort to do so. The other area I am extremely interested in is clustering, to see how much performance you could squeeze out by adding multiple machines.
Talking about clustering, see this one: http://www.alchemi.net/
maybe it can help, or, suggest some kind of implementation for db4o
Post a Comment