Lealone 8.0.0-SNAPSHOT: an in-process SQL agent that generates and runs services

The problem Lealone targets: service definitions that never leave the database

Most teams describing a small internal service write the same thing twice: once as a schema, once as handler code. Lealone collapses that. A service is declared with create service, its methods are declared inline with typed parameters and a return type, and the server exposes each method over HTTP at /service/<service_name>/<method>. The README shows the full shape: create service if not exists my_service ( hello(name varchar) varchar, get_current_time() varchar ); and then a call at http://localhost:8080/service/my_service/hello?name=zhh. There is no controller class, no route registration, no serialization layer to write. The audience is engineers who want a working endpoint in one file and are comfortable with a database being the deployment unit. It is a poor fit for anyone whose services need framework-level middleware, dependency injection, or a separately deployable artifact per service.

How the agent, services and workflows fit together in one process

The README describes three layers that share a JVM. The base layer is the database: the topics list acid, oltp, replication, sharding and newsql, and the sample schema uses ordinary DDL such as create table if not exists user ( id long auto_increment primary key, name varchar, age int ). The second layer is services and workflows, declared in the same SQL dialect and persisted alongside tables, which is why a single services.sql file can define both schema and behaviour. The third layer is the agent, launched with the -agent flag, which reads natural language and produces a running application; the README states that entering a prompt for a todo app returns a URL after roughly twenty seconds. Workflows add an intent layer: create workflow if not exists my_workflow ( start(name varchar) varchar comment '找到指定的用户，然后跟他打招呼，把当前时间告诉他' ); the comment carries the instruction, and the workflow is expected to chain the user lookup and the greeting. The material does not explain how the workflow engine resolves that comment into steps, so treat the chaining as documented intent rather than a verified execution model.

Building and starting Lealone with JDK 21

The build command in the README is mvn assembly:assembly -Dmaven.test.skip=true, and the stated requirement is JDK 21 or newer, linked to Oracle's download page. The README also offers a prebuilt lealone-8.0.0-SNAPSHOT.jar hosted on the project's GitHub Pages site, so a build is optional if you only want to try the runtime. Starting the database server is java -jar lealone-8.0.0-SNAPSHOT.jar. Starting the agent instead is java -jar lealone-8.0.0-SNAPSHOT.jar -agent. To run a file of declarations directly, pass it as an argument: java -jar lealone-8.0.0-SNAPSHOT.jar services.sql. Note the mismatch between the artifact version and the release list: the jar is 8.0.0-SNAPSHOT while the newest tagged release given is lealone-6.0.1 from 2024-08-18. If you pin dependencies, you are pinning a snapshot unless you check the releases page yourself.

Configuring the model provider with set llm

Model configuration happens inside the agent window, not in a properties file, and the README says it only needs to be done once. The syntax is a SQL statement with named parameters: set llm ( provider: 'doubao', model: 'doubao-seed-2-0-pro-260215', api_key: '替换成你的apikey' );. Two providers are named in the comment, doubao and deepseek, so the provider value is a closed set as far as the documentation goes. Three practical consequences follow. First, the API key is entered into an interactive prompt, and the material says nothing about where it is stored afterwards, so anyone evaluating this for a shared environment should determine that before use. Second, the model identifier is written literally, which means a provider-side deprecation of doubao-seed-2-0-pro-260215 breaks the agent until the statement is re-run. Third, because configuration lives in the agent session, the agent is not something you can currently drive from a checked-in config file the way you would drive a build.

Where the documentation stops and guesswork begins

The README is a quickstart, not a reference. It never states what happens when a service method throws, whether concurrent HTTP requests to the same service are serialized against the database transaction, how workflow steps are retried, or what the agent does when the model returns something that is not valid SQL. Those are the questions that decide whether this belongs in front of real traffic. There is also a version gap that the material makes visible rather than resolves: the releases listed stop at lealone-6.0.1 while the build and run instructions all reference 8.0.0-SNAPSHOT. A team that needs a fixed, auditable artifact has to reconcile that themselves. The licence is a further unknown. GitHub reports NOASSERTION, and the README points to LICENSE.md in the repository without describing its terms, so this article cannot tell you what obligations attach to redistribution. Read that file directly; do not infer a licence from the topics or from the fact that the source is public.

Lealone against a conventional Spring Boot plus JPA stack

The obvious comparison is Spring Boot with JPA or MyBatis. In that stack, the database is a dependency you configure and the service is Java code you compile; adding an endpoint means writing a class, annotating it, and rebuilding. Lealone inverts the direction: the declaration is the artifact, and the runtime interprets it. The trade is real. Spring gives you a mature ecosystem of filters, security integrations, test harnesses and a decade of operational knowledge, at the cost of boilerplate and a build cycle. Lealone gives you one file and an HTTP route per method, at the cost of visibility into how that file becomes a running, concurrent service. The agent layer has no direct equivalent in Spring; the closest analogue is a code generator, except Lealone runs the output in the same process rather than emitting source you review first. If your team's review process depends on reading generated code before it reaches an environment, that difference matters more than the saved boilerplate.

Maintenance surface and what a snapshot dependency costs

Three things generate ongoing work here. The first is the LLM dependency: provider, model name and API key are all configuration you own, and the model identifier in the README is a dated string that will eventually be retired by the provider. The second is the version skew between the documented SNAPSHOT jar and the last tagged release, which means upgrade planning has no stable target described in the material. The third is the agent's output. The README says a prompt returns a URL after about twenty seconds, which implies generated code or generated service definitions; nothing in the material describes a review step, a diff, or a way to accept the result into version control. On licensing, the only accurate statement is that GitHub classifies the repository as NOASSERTION and the README links to LICENSE.md. Whether you can ship Lealone inside a closed product, and under what conditions, is a question for that file and for your own counsel, not for this article.

Editorial conclusion

Adopt Lealone if you want to prototype HTTP services and workflows inside a single Java process and you are willing to run JDK 21+ and paste an LLM API key into an interactive SQL prompt. Do not adopt it if you need a stable, versioned API surface, a clearly identified open source licence, or a supported release train: the README documents a SNAPSHOT jar, the most recent tagged release listed is lealone-6.0.1 from August 2024, and the licence file is not classified by GitHub. Before committing, run java -jar lealone-8.0.0-SNAPSHOT.jar services.sql against your own services.sql, confirm the generated /service/... endpoints behave, and read LICENSE.md yourself to decide whether its terms fit your distribution model.

Official sources

1. Issues
2. lealone/Lealone on GitHub
3. README
4. Releases