db2rest: a Java service that turns a relational schema into REST endpoints without code generation

The engineering problem db2rest removes

A team that needs to read from a table over HTTP usually writes the same layer again: a controller, a repository, a DTO, a serializer, and a migration path for each schema change. db2rest replaces that layer with a running service. The README describes it as a low code REST DATA API platform that "automatically creates a secure REST API endpoint for your databases" with "No ORM, no code generation". That sentence is the whole product thesis. The intended users are teams building internal tools, partners needing read access to a subset of tables, and developers wiring function or tool calls for an LLM application that has to fetch rows from an existing relational store. The README also frames it as a secure database gateway, which is a fair description of the deployment shape: the service sits between callers and the database, and the database itself is not exposed.

What the architecture implies about data flow

The repository is a Spring Boot application written in Java, which tells you most of what you need about the runtime. Configuration is read at startup, a connection pool is created per configured database, and incoming HTTP requests are translated into SQL against the tables the configuration names. There is no generated client and no compile step tied to your schema. The README's build instructions confirm the packaging model: `mvn clean package` from the repo root produces the artifact, and the release table offers a single jar per version, for example DB2Rest-1.6.8. The supported database list is broad and includes older engines, Oracle 9i and 10g among them, plus IBM DB2 11.5.8.0 and later. That breadth is deliberate. It is also the reason the service cannot rely on modern-only SQL features across every backend, so expect the generated statements to stay within a conservative dialect.

Getting a jar or container running

Two paths are documented. The release table gives a jar download at download.db2rest.com/db2rest-1.6.8.jar and a container image, `docker pull kdhrubo/db2rest:v1.6.8` or `kdhrubo/db2rest:latest`. The README points to db2rest.com/docs/intro for on-premise or virtual machine installation and db2rest.com/docs/run-db2rest-on-docker for the container path. Those two pages are where the actual connection properties live, and the README does not reproduce them, so treat the docsite as the source of truth for keys such as the JDBC URL, driver class, username and password entries. If you build from source instead, the documented command is `mvn -Drevision="1.5.4-SNAPSHOT" clean package -DskipTests`, with `revision` overriding the version in the POMs. Tests need a running Docker daemon because the build pulls testcontainers for the database tests, which is a reasonable signal that the database integrations are exercised in CI rather than mocked.

Where the no-code model breaks down

The value of db2rest comes from constraining what a request can express. That same constraint is the failure mode. Anything that needs a join across several tables with a computed projection, a window function, or a write that must commit atomically with a second write is outside the shape of a table-to-endpoint mapping. The README does not document a transaction boundary spanning multiple HTTP calls, and you should not assume one exists. There is a second, quieter problem: the service becomes a second place where access rules live. If your application already enforces row-level visibility in code, exposing the same tables through db2rest creates a parallel path that has to be kept in step. The README's claim that best practices are built in is a statement about defaults, not a substitute for reviewing what each exposed table reveals. The Oracle 9i build is a separate artifact at version 1.2.3, marked final, so teams on that engine are on a different and older line than the 1.6.8 release.

How it differs from PostgREST and from hand-written controllers

PostgREST is the closest well-known comparison, and the difference is scope rather than features. PostgREST targets PostgreSQL and derives its API from the database's own catalog and roles, so the database remains the single source of authorization truth. db2rest spreads across PostgreSQL, MySQL, SQLite, MS SQL Server, Oracle, IBM DB2, MariaDB, CockroachDB, Neon and the managed variants of Postgres and MySQL, and its configuration lives in the service, not in the database. If your schema is PostgreSQL and your team already manages grants carefully, PostgREST keeps one policy surface instead of two. If you have an Oracle 9i instance and a MySQL instance that both need the same style of endpoint, db2rest is the option that covers both with one operational model. Against a hand-written Spring controller, the difference is maintenance: the controller gives you arbitrary query logic and costs you a release per schema change.

Maintenance, releases and the licence position

The project is under active release, with 1.6.8 published on 2025-12-21 after a release candidate and a snapshot in the preceding days, and the repository's last push is dated 2026-09-03. The version scheme is plain semantic versioning with RC and SNAPSHOT pre-releases, so pinning to 1.6.8 rather than `latest` is the sensible default for anything beyond a local trial. The licence is Apache-2.0, which permits commercial use and modification and requires that you preserve notices and state changes; it also includes a patent grant. That covers the db2rest code. It does not cover the JDBC drivers you supply for Oracle, IBM DB2 or MS SQL Server, which carry their own terms, and it does not cover your database's own licensing. Review both before shipping, and treat this paragraph as a pointer to the licence files rather than as legal advice.

Deciding whether this belongs in your stack

The clearest fit is a read-mostly scenario: a small number of tables, a known set of consumers, and a requirement to have JSON over HTTP this week rather than next quarter. The GenAI angle in the README is the same scenario with a different caller. An LLM tool call needs a predictable endpoint that returns rows, and db2rest provides that without a bespoke function per table. The clearest misfit is a domain with invariants that span tables, or one where the query planner needs hand-shaped SQL to meet a latency target. In between are the cases worth a pilot: teams that want to test whether the configuration model survives contact with real access rules before rewriting an existing API layer. Run the 1.6.8 jar against a copy of the schema, list every table you expose, and check what a caller with the weakest credentials can read through the generated endpoints.

Editorial conclusion

Adopt db2rest when a fixed set of tables has to become HTTP JSON quickly, when the database is one of the listed engines (PostgreSQL, MySQL, SQLite, MS SQL Server, Oracle including 9i and 10g, IBM DB2 11.5.8.0+, MariaDB, CockroachDB, Neon), and when a gateway in front of it already handles authentication and rate limits. Do not adopt it when queries need multi-statement transactions, hand-tuned SQL plans, or column-level rules that change per caller; that logic belongs in an application or a database view. Before committing, verify three things against the 1.6.8 jar: the exact property names for your database in db2rest.com/docs/intro, whether your licence position permits Apache-2.0 plus the JDBC driver terms, and how the service resolves tenant identity for row filtering.

Official sources

1. 9tigerio/db2rest on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases