IronDoc will typically only be slower than other databases for specific operations that the other databases are almost specifically architected to effect with best possible time. Of course, when the collection under consideration is the N bytes being read or written, such operations are necessarily linear ones. IronDoc might only suffer in comparison to databases performing very large contiguous reads and writes of streams, when other databases might always store such streams contiguously no matter how large. When enough memory is used to buffer a good percentage of a working set in memory, the performance should be exceptionally good. This is even more true with IronDoc than for some other databases because IronDoc does not maintain significant redundant data structures in memory when these data structures also exist persistently in a file.
Most content is stored in either blobs or in btree dictionaries.
Actually both blobs and dictionaries are btrees that IronDoc transparently maps onto raw block interfaces. An IronDoc blob is extremely similar to a file in a file system. Blobs eight bytes or less are actually immediates in the uid dict. A btree dict maps a uid to a blob's type and to the physical location of a blob's content bytes. The type uid of every blob is intended to be a MIME type that is registered with yet another btree dict in the database, but this cannot be strictly enforced.