"Inside db4o," by Rick Grehan, explores the surface of db4o, an open-source object database. db4o has implementations for Java, .NET, and Mono, persists object trees to a database, and provides some very flexible and powerful query capabilities.

db4o is a database engine, available as a single .jar file that you include in your database application’s classpath (for Java, at least.) So, db4o runs in the same process space as your application and is called directly; it does not employ drivers in the sense of ODBC or JDBC. Versions of db4o exist for Java, .NET, and Mono; and all are functionally equivalent to one another. (In fact, a db4o created with a .NET language can be accessed by Java, and vice versa.) db4o is open source. Executable, source, and documentation can be downloaded from www.db4objects.com. Extensive examples, as well as an active user community, can also be found at the website. One of db4o's most attractive features is its remarkable balance of simplicity and power. On the one hand, its API is so easily mastered and readily grasped that even a neophyte can create a full-fledged database application in a single sitting. On the other hand, that same API provides lower-level calls into the database engine that admit hardcore developers into the engine's plumbing in order to tweak and tune db4o's equipment for optimum performance. db4o's characteristics are best illustrated -- rather than merely discussed -- so we will take the approach of demonstrating db4o through example. Throughout this article, however, keep in mind that we are showing only a portion of db4o's features. Interested readers will find that time spent investigating the db4o documentation in discovery of this database engine's complete abilities is time well spent.

"db4o is open source" .. but not gratis.

So if you keep your software free, it's gratis. Otoh if you don't want to make your software free, you can't use the free version and you pay for the commercial license. So yes it's gratis for free software and payware for non-free software. Same as MySQL ftm.

Is this a Java community or a SPAM/Fanboy site for a couple of people to throw half assed press releases to the masses? Believe me the quality of the articles reflects it.

Have a look at NeoDatis ODB which is equivalent and is free for any type of use http://odb.neodatis.org

Is db40 supposed to compete with standard RDBMS (mysql, postgres, Oracle ...) or it aims to a particular niche? How does it compare with Hypersonic? It is a single jar, but it can also run in server mode to serve multiple clients. Thanks, Paul Brenoir Sr Developer jbilling.com The Enterprise Open Source Billing System

Is db40 supposed to compete with standard RDBMS (mysql, postgres, Oracle ...) or it aims to a particular niche? How does it compare with Hypersonic? It is a single jar, but it can also run in server mode to serve multiple clients.

It's not an RDMS at all. I'd say that relational systems manage large amounts of homogenous data well, whereas object databases handle heterogenous data well. You choose which one you need based on your datasets. As far as how it compares with HSQL/HSQLDB/H2... well, they're relational, db4o isn't. It has a client/server mode, which db4o says is improving all the time. I've found it to still be a little problematic.

Thanks Joseph. I find the start of the article 'db40 is a database engine', rather confusing then. I would expect from a 'database engine' to handle large amounts of data... can you tell me an ideal scenario where db40 would be a perfect fit? Thank you! Paul Brenoir Sr Developer jbilling.com The Enterprise Open Source Billing System

Thanks Joseph. I find the start of the article 'db40 is a database engine', rather confusing then. I would expect from a 'database engine' to handle large amounts of data... can you tell me an ideal scenario where db40 would be a perfect fit?

Well, databases are repositories for data - they don't make an assumption of size, large *or* small, except in specific application. That said, db4o is supposedly workable for large datasets, although I've not put it through its paces. Like I said, I find db4o very useful for heterogenous datasets... as in accounts with debits and credits, comments interspersed with other data indexed on time, etc.

Well, databases are repositories for data - they don't make an assumption of size, large *or* small, except in specific application.

That said, db4o is supposedly workable for large datasets, although I've not put it through its paces.

Well, the article seems to mention that the only limit is... memory size ! And the whole db is stored in one single file... I'm afraid it won't be enough for "large" dbs ;-P Cheers Remi

Well, databases are repositories for data - they don't make an assumption of size, large *or* small, except in specific application.

That said, db4o is supposedly workable for large datasets, although I've not put it through its paces.

Well, the article seems to mention that the only limit is... memory size ! And the whole db is stored in one single file...

I'm afraid it won't be enough for "large" dbs ;-P

Cheers

Remi

Well, it's not a prevayler-style db. The phrase you're quoting is, I think, this one:

... which means that db4o's persistence limitation is set by available memory more than anything else.

This doesn't mean it stores everything in RAM; it means that the specific instance tree being persisted is limited by RAM. As far as the one-file issue, well, I have no further information on that.

And the whole db is stored in one single file...

Errm, where is a MySQL db stored for that matter ? In a file with suffix "frm" normally. db4o operates in server mode or file mode. So lets get back to real facts for doing a fair comparison

Errm, where is a MySQL db stored for that matter ? In a file with suffix "frm" normally. db4o operates in server mode or file mode. So lets get back to real facts for doing a fair comparison

I don't think MySQL stores everything in one file. It's one table per file if I'm right. And I don't bash db4o, it looks pretty cool actually, and maybe for certain usages it's just fine (e.g. probably everywhere you need small footprint and embedded data storage, it obvisouly seems better than a relational embedded engine). It's just that in-memory trees are not enough sometimes, and believe what you want, but real life "large" dbs span on several hard disks ! So I wanted to correct that, as somebody asked if db4o could handle "large" dbs. And finally, comparing to MySQL isn't fair anyway ;-P I would more like to know how db4o compares to Caché or Versant... Cheers Remi

And I don't bash db4o, it looks pretty cool actually, and maybe for certain usages it's just fine (e.g. probably everywhere you need small footprint and embedded data storage, it obvisouly seems better than a relational embedded engine).

How often do you need just a small embedded database, though? Dunno, maybe I'm just in the wrong industry but I tend to think of databases as repositories of shared data that multiple people use. That said, how is db4o with multiple concurrent users? Do object DBs have issues with record locking, or is that concept foreign? How does it handle transactions? Or is it more like a muscle car, and we're not supposed to ask about the gas mileage? ;)

You could try finding out for yourself. Set it up, make up some persistence objects that form a composition, then instantiate lots of objects and link them into variable-sized trees and sling the trees into the database. Then pull them out. Then update them. You know; investigate. Then tell us some facts.

You could try finding out for yourself.

Dude, thanks a lot for this brilliant suggestion !! I hadn't thought about that ! And next time I buy a car, I'll learn mechanics before, and disassemble everything myself to check if it's ok... Who knows, maybe the so called experts didn't do the right job, I prefer to be sure by myself than to read the manual or ask the constructor ! Cheers Remi - trust no one

Hi! Just to make things clear I just wanted to answer some of the questions in this thread: It's not a 1:1 competitor wih RDBMSs. There are many usecases where a relational database makes more sense than db4o (e.g. central corporate database for many applications, usecases where data is flat and requires few joins, etc). However there might be some overlapping usecases such as some web applications. The idea of an object database is NOT a shared repository between many applications but a one-to-one app db relationship. Caches, devices, packaged software, SCADA systems are typical usecases. It's not a replacement for RDBMS technology but brings persistence to places where RDBMSs fall short. How does it compare to other lightweight object databases in the market? db4o is open source and thus more affordable than proprietary OODBSs, it's a native database (Java/.NET), it's easy to use and deploy, and, according to benchmarks, performance is superior. Best.