How do their APIs compare?

These two projects have fundamentally different domains, so their APIs compare more in style/philosophy than in overlapping functionality. Here's the breakdown:

Different problem domains

• mapdb is an embedded storage engine exposing Java collection interfaces (Maps, Lists, Sets, Queues) backed by disk or off-heap memory. Its API surface is about data structures.
• mybatis-3 is a SQL mapping/persistence framework. Its API surface is about sessions, statements, and object/relational mapping.

They aren't really substitutable — mapdb replaces a database with in-process collections, while mybatis-3 sits on top of a JDBC database to map SQL results to Java objects.

API entry-point style: both use a "Maker/Builder" pattern

• mapdb: DB.Maker is a static-factory builder — Maker.memoryDB() / Maker.heapSer() return a Maker wrapping a Store, and .make() produces the usable DB object [src/main/java/org/mapdb/db/DB.java:L24-L43]. Individual collections follow the same convention, e.g. MonolithList.Maker.newList(store, ser) then .make() [src/main/java/org/mapdb/list/MonolithList.java:L11-L23]. The README's "Hello world" example shows the public-facing version of this: DBMaker.memoryDB().make() then db.hashMap("map").make().
• mybatis-3: SqlSessionFactoryBuilder/config-driven builders play an analogous role, but instead of returning collections, they return a SqlSessionFactory → SqlSession, from which typed mapper interfaces are obtained. Configuration itself is largely externalized into XML processed by XMLConfigBuilder, which walks child elements to wire up TypeAliasRegistry, TypeHandlerRegistry, ObjectFactory, TransactionFactory, DataSourceFactory, plugins/interceptors, etc. [src/main/java/org/apache/ibatis/builder/xml/XMLConfigBuilder.java:L174-L253, L334-L373]. So mybatis's "builder" is really an XML-driven configuration assembler, not a fluent code-only builder like mapdb's.

Core abstraction surfaced to users

• mapdb: the central interface is Serializer<K> — every stored type needs one, and it doubles as a Comparator<K> (serialization + ordering + hashing + equality all bundled in one interface) [src/main/java/org/mapdb/ser/Serializer.java:L15-L67]. Collections like MonolithList are thin wrappers over a Store + Serializer, delegating all get/put operations to store.get/update with a serializer for encoding [src/main/java/org/mapdb/list/MonolithList.java:L46-L104]. This means mapdb's API forces users to think about serialization explicitly and early.
• mybatis-3: the central abstraction instead is declarative — SQL is attached to a Java method via annotations like @Select (with dynamic SQL support) [src/main/java/org/apache/ibatis/annotations/Select.java:L24-L38], @SelectKey for generated keys [src/main/java/org/apache/ibatis/annotations/SelectKey.java:L27-L37], and @Results/@Result for column-to-property mapping including nested @One/@Many associations [src/main/java/org/apache/ibatis/annotations/Results.java:L23-L38, src/main/java/org/apache/ibatis/annotations/Many.java:L23-L28]. Users write interface method signatures and SQL strings; mybatis handles binding and result mapping — serialization concerns are pushed into TypeHandlers configured separately, not baked into every call site.

Extensibility hooks

• mapdb extensibility is largely through implementing Serializer (pluggable encode/decode/compare/hash for custom types) and through Store/Volume implementations for different storage backends (heap, memory-mapped file, FileChannel) [src/main/java/org/mapdb/store/legacy/Volume.java:L196-L235, L276-L290].
• mybatis-3 extensibility is through Interceptor plugins, ObjectFactory, `ObjectWrapperFact