If db4o cannot find a more specific typehandler for a type it will fall back to the StandardReferenceTypeHandler. That means the type will be handled as a complex object.
Types handled by the StandardReferenceTypeHandler carry some interesting properties:
Db4o will pretend that objects of this type have an identity
Indexing happens at id level
A class index entry will be created for every stored object
These three points have some interesting implications for value types on the .Net platform. By definition, Value Types have no identity so it makes no sense to db4o to keep an id for such types. Also, db4o handles types with no identity by embedding marshalled instances into their parent's slots, which in most cases will induce less overhead (no need to keep track of ids), potentially resulting in better performance.
Since we didn't have a specific typehandler for System.Guid this is the status quo for this type in db4o in versions prior to 7.12. As we continue to improve db4o, we strive to make its usage as natural and its performance as high as possible on each platform it's designed to run on. We are proud to announce that based on the contribution from Judah Himango, a community member, we are introducing a new typehandler for the System.Guid, so starting with db4o 7.12, System.Guid has got it's own (deserved) type handler with better indexing support, no more artificial ids and less overhead.
You may be wondering what will happen to old databases when they get updated to version 7.12. As always the database format update should be transparent and require no effort from developers; as objects holding guids get updated they will use the new typehandler.
You can use Db4oTestRunner with GuidTypeHandlerTester to see it with your own eyes (you can even try with different db4o versions ;)
Alternativally you can grab Db4oTestRunner / GuidTypeHandlerTest sources from our SVN.
Your db4o team.