bee is a Java ORM that removes the DAO layer instead of generating it

The Suid interface and the DAO you no longer write

bee is a Java ORM, and the design decision it is built around is the removal of the DAO layer rather than the generation of one. The claim in the documentation is that coding complexity is O(1) in the sense that the framework does the DAO work for you, and that you can call the API directly for database operations instead of writing separate DAO code.

The entry point is the Suid interface, which provides four object-oriented methods corresponding to the select, update, insert and delete operations of SQL. Below that sit conventions and defaults. A Javabean entity needs no annotation and no XML, and null and empty string properties are filtered out automatically, so the null checks that normally clutter an entity layer disappear.

Beyond the four verbs, the API covers partial field queries and native statement pagination, returning query results in JSON format with chaining, and dynamic or arbitrary combinations of query conditions that do not need DAO interfaces prepared in advance, so a new query requirement does not mean a new interface method. Transactions, FOR UPDATE, batch processing, native SQL and stored procedures are all listed as supported, using the same connection across multiple ORM operations.

The relationship story is the one that decides whether a mapper or an ORM is the right shape. bee supports one-to-one, one-to-many, many-to-one and many-to-many, multi-table queries without the N+1 problem, and a result structure that depends on whether the sub-table is a List.

What the twenty six feature claims actually cover

The documentation numbers its features, which makes the scope easy to audit and also easy to read as marketing. Pulling out the substantive ones gives a clearer picture.

On the storage side, there is MongoDB ORM with MongoDB sharding, multiple databases used simultaneously such as MySQL, Oracle and SQL Server at once, and extension to any database supported by JDBC, with MySQL, MariaDB, Oracle, H2, SQLite, PostgreSQL, SQL Server, Access, Kingbase and Dameng named, plus Android and Harmony support. Pagination support extends to MsAccess, Cubrid, HSQL, Derby and Firebird.

On the query side, there are custom dynamic SQL tags such as @in, @toIsNULL1, @toIsNULL2, <if isNotNull> and <if isNotBlank>, which turn a list into an in (1,2,3) statement without a foreach loop, and batch insertion without a foreach either.

On the infrastructure side there are register, interceptor, multi-tenancy and custom TypeHandlers, an L1 cache described as fine tunable like the JVM with an updatable long-term cache list and a configuration table that can be changed without a restart, L2 cache extension with Redis support, and a claim of inherent resistance to cache penetration.

Two numbers are worth repeating because they are checkable. The documentation states there are no third-party plugin dependencies and that the library can be used with zero configuration, and it gives the size as 969k for version 3.0.0, with an earlier 1.17.25 release at 520k.

Sharding that is meant to disappear into the API

Sharding is the feature the documentation spends the most space on, and the stated goal is that it is mainly transparent to business development and coding, with only a little sharding configuration.

The supported shapes are database and table sharding together, database only, table only, and read-write separation, all of which the documentation says work with existing code and need no additional coding. The 3.0.0 line extends that to the multi-table features: MoreTable select, insert, update and delete all support sharding, MoreTable select supports sharding, and MoreTable join supports update, insert and delete.

The release notes for 3.0.0 show where the sharp edges are. The sharding SQL was adjusted for order by and group by parts that are not in the select list, sharding auto-generated columns for group by, order by and avg were removed, MoreTable sharding sort was added, and MoreTable select of averages under sharding was added. A bug was fixed where a sharding select failed when there was no group by. The 2.5.10 line lists its own sharding bug fixes in AbstractCommOperate and in ObjSQLRich, and a missing parameter fix on a select overload.

That is the honest picture of sharding in any ORM: the configuration is small and the SQL rewriting is not. The repository keeps a dedicated 2.0-sharding.md file and a guide/Quick-start-Sharding.md, which is where the details live.

Entity conventions and the annotation changes in 3.x

The framework leans on entity conventions, and the 3.0.0 release notes show the conventions being tightened. Fields can be referenced through the entity name with a _F suffix, for example Users_F.name, or in the SuidRichExt interface with the format Users::getName, which means a field can be named dynamically without being compiled into the call.

The annotation surface is broad: PrimaryKey, Column, Datetime, Createtime, Updatetime, plus JustFetch, ReplaceInto for MySQL, Dict, DictI18n and GridFs. DDL generation was extended in 3.0.0 so that creating a table from an entity supports @StringLen and @ColumnType, and supports @NotNull and @Unique.

The multi-table API in 3.0.0 also changed how a foreign key is written. The documentation shows the old form and the new form side by side:

@FK(refBy = "id", value = "classno")  
->  
@FK(mainField = "id", subField = "classno")  

And the subClass property moved from a string to a class literal:

subClass = "Student"  
->
subClass = Student.class  

Two concrete breaking changes in a single release, both in the area most likely to be used heavily, which is a good argument for reading the notes before upgrading rather than after.

Generation, Excel import and the debug-friendly SQL

The assistive features are unusually broad for an ORM, and two of them are about development rather than runtime.

Code generation is the first. The documentation lists automatic generation of Javabean classes corresponding to tables, with Swagger support, creating tables based on a Javabean, and automatic generation of backend Java web code based on templates. For debugging it can print executable SQL statements without placeholders, and it can generate SQL scripts in JSON format. Printing the statement without placeholders is a small feature with a large effect on how fast you can diagnose a wrong query, because you can paste it straight into a client.

The second is data import. Excel files can be read and imported into the database with simple operations, and database tables can be generated from Excel configurations. That is a differentiator for shops whose data starts in spreadsheets.

There are utility classes too, a StreamUtil and a DateUtil that does date conversion, judges date format and calculates age.

For distributed primary keys, the documentation describes a natural solution that generates globally unique, monotonically increasing numeric IDs within a worker ID, which is the shape you need when several services insert into the same table. It is a snowflake style approach described in the feature list rather than in a dedicated section, so the details on worker ID assignment and clock drift would have to come from the source.

Where the version story and the documentation disagree

This is the part to slow down on before installing anything.

The README announces that the newest version is Bee V3.0.0 LTS, and describes it as 969k. The recent releases list tells a different story: v2.5.2 with the title MongoDB Sharding and CQRS published on 2025-08-02, V2.4.0 on 2024-09-27, and V2.1.8 on 2023-10-05. So the version the README promotes is not among the tagged releases shown, and the 3.0.0 feature list that follows it is presented as the newest main function while the release history stops in the 2.x line.

The README does describe a second maintenance line, V2.5.10, as 2.5.x LTS, with a short list of enhancements and sharding bug fixes. So the picture is a 3.x line under development in the documentation, a 2.5.x line described as LTS, and a set of tags that does not obviously include either.

The last push was on 2026-09-06, and the repository is not archived, so the work continues. The requirement is jdk1.8 and later, and the 3.0.0 notes add support for JDK 21 virtual threads, which is a useful signal that the 3.x line is aimed at modern server deployments while the 2.x line remains the conservative choice.

The documentation set has the same split. Alongside README.md and README_CN.md there are Changed_Log.md, Changed_Log_CN.md, Changed_Log_Main_CN.md and FAQ_CN.md, a guide/ directory, an api doc/ directory, an illustration/ directory, main-feature.md and 2.0-sharding.md. Reading a Chinese-language changelog and FAQ is a real requirement for a non-Chinese-speaking adopter.

The alternative, and where an ORM is the wrong shape

The alternative to a DAO-free ORM is not another ORM, it is a mapper with SQL you control. In that style, each query is a statement you wrote, mapped to a method on an interface, and the framework handles the plumbing around it. The difference in approach is precise: a mapper makes the SQL explicit and the API surface a consequence of your SQL, while bee takes an entity and a runtime condition object and derives the statement, which is why it can offer dynamic condition combinations and JSON output without you writing a query.

The cost of that approach is that the SQL is no longer the primary artefact. When a query is slow, the generated statement has to be inspected rather than read, and the documentation's own print-executable-SQL-without-placeholders feature is an admission of that. For a reporting workload or a schema where the query shape matters, that is a meaningful trade.

The second case where bee is the wrong tool is a requirement it does not meet. It has no notion of a hand-written repository interface, so a team whose reviewers want to see every query in the repository is out of luck. And a team that wants a small dependency with one job will find the feature list heavy: sharding, MongoDB, code generation, Excel import, distributed IDs, multi-tenancy and two cache tiers are all in the same artifact.

The licence is Apache-2.0 with the LICENSE file at the repository root, and the wider family includes bee-ext, a Python ORM called BeePy, and the AiTeaSoft project, so an adopter is choosing a stack rather than an isolated library.

Editorial conclusion

bee fits a Java team that wants a runtime API for CRUD and dynamic conditions without maintaining one DAO interface per table, and who also need sharding or MongoDB without bolting a second library onto the project. It does not fit a codebase that needs hand-written SQL per query, and it does not fit a team unwilling to read a documentation set that is largely Chinese and split across a guide directory. Before adopting it, check which line you would actually install, since the README names Bee V3.0.0 LTS while the newest tagged release shown is v2.5.2, and confirm your JDK, because the stated requirement is jdk1.8 and the 3.x line adds support for JDK 21 virtual threads.

Frequently asked questions

Official sources

1. automvc/bee on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases