db2rest: a no-code REST data API for relational databases

The problem db2rest removes: writing a data access layer for every database

Most teams that need to expose a database over HTTP write the same layer again and again: controllers, DTOs, query builders, pagination, filtering, and the mapping code between them. db2rest takes the position that this layer is mechanical. Its README describes it as a "modern low code REST DATA API platform that automatically creates a secure REST API endpoint for your databases," and states the goal as no ORM and no code generation. That distinction matters. Code generators produce source you then own and maintain; db2rest produces endpoints at runtime, so the API surface follows the schema rather than a generated snapshot of it.

The intended audience is narrower than the marketing suggests. It fits teams that already have a relational schema and want HTTP access to it quickly, teams building GenAI applications that need function or tool calls backed by real data, and enterprises that currently move data between systems with file exports. The README names that last case directly, describing SFTP and S3 exports as slow, complex and not realtime. If your API needs business logic between the request and the table, this is not the layer for it.

How db2rest maps a relational schema onto REST endpoints

The repository is split into modules: db2rest-api, db2rest-auth, db2rest-core and db2rest-dialects. That layout tells you the architecture without running anything. Dialect support is isolated in its own module, which is how the project covers PostgreSQL, MySQL, SQLite, MS SQL Server, Oracle, IBM DB2, MariaDB and CockroachDB from one codebase. Authentication is also a separate module, which means the security layer is pluggable rather than baked into request handling.

The runtime is a Spring Boot application. The Dockerfile builds on bellsoft/liberica-runtime-container:jre-21-cds-slim-musl and runs a single jar, db2rest.jar, with the entrypoint java -jar db2rest.jar. The commented-out EXPOSE 8080 line in that Dockerfile documents the default service port as 8080, and the comment notes you can map it on docker run with -p 1234:8080 instead. There is also a db2rest-oas3.json file at the repository root, which is the OpenAPI description of the service. That file is the practical way to see what endpoints exist, because the README does not enumerate them.

The data flow is direct. A request arrives, the dialect layer translates it into SQL for the configured database, and the result is serialized back. There is no intermediate object graph, which is exactly why the README can claim no ORM. The cost of that design is that the shape of your tables and columns is the shape of your API. Rename a column and you have changed a public contract.

Running db2rest with Docker and pulling the release jar

The README points to two installation guides rather than inlining the steps: an on-premise or virtual machine guide and a Docker guide, both on db2rest.com/docs. What the README does give is the artifact for release 1.6.8. For Docker, the published image is kdhrubo/db2rest, tagged either with the version or as latest.

docker pull kdhrubo/db2rest:v1.6.8

Pulling by explicit version rather than latest is the safer default here, because the tag is the only thing tying the image to a release. For a jar-based install, the README links the download directly.

java -jar db2rest-1.6.8.jar

The Dockerfile confirms the container listens on port 8080 by default, though the EXPOSE instruction is commented out, so you must publish the port yourself.

docker run -p 1234:8080 kdhrubo/db2rest:v1.6.8

After the container starts, the service is reachable on the host port you mapped. The exact connection configuration for your database is not in the README; it lives in the on-premise installation guide, so treat that page as required reading before the first run. For building from source, the README gives the Maven invocation and a revision override.

mvn -Drevision="1.5.4-SNAPSHOT" clean package -DskipTests

Note that the README's testing section requires a running Docker daemon, because the build pulls and runs testcontainers for the database tests.

Where db2rest is the wrong tool

The most honest limitation is the one the design implies rather than states: db2rest exposes tables, so any consumer of the API can reach whatever the configured database user can reach. The README calls it a "secure database gateway" and the db2rest-auth module exists, but the README does not document the default authentication behaviour, the token format, or how per-table authorization is configured. Until you read the auth module or the docsite, you should not assume a fresh instance is locked down. That is a verify-first item, not a reason to reject the project.

A second limitation is version and database coverage. Oracle support is split: the current line covers Oracle including 9i and 10g, but the README also lists a separate "Last Stable Oracle 9i Release" at 1.2.3, marked Final. If you are on 9i, you are being pointed at an older artifact, and that is a real fork in the upgrade path. The planned database list (Yugabyte, PlanetScale, CrunchyData, MindsDB, DuckDB) is explicitly planned, not shipped, so do not design around it.

Third, the abstraction itself is the constraint. Because there is no code generation, there is also no generated place to put validation, rate limiting per field, or cross-table business rules. Teams that need a hand-shaped API with a stable contract independent of the schema will fight this design rather than benefit from it.

db2rest compared with PostgREST and hand-written Spring controllers

The obvious alternative for PostgreSQL shops is PostgREST, which also derives an HTTP API from a database schema. The difference is scope. PostgREST is PostgreSQL-only and leans on database roles and row-level security for authorization, so the security model lives in the database. db2rest is multi-dialect by construction, with db2rest-dialects handling PostgreSQL, MySQL, Oracle, SQL Server, DB2, MariaDB, SQLite and CockroachDB, and it puts authentication in a separate Java module instead. If your estate is mixed, that difference decides the choice. If it is PostgreSQL-only and your team already thinks in database roles, PostgREST keeps the policy in one place.

The other alternative is what most teams already have: Spring Boot controllers over Spring Data or JPA. That gives you full control over the API contract and where validation happens, at the cost of writing and maintaining the mapping layer. db2rest is the same runtime family, Spring Boot and Java 21, so the migration story is not about a foreign stack. It is about whether you want the schema or the code to be the source of truth for your API.

Licence, maintenance and upgrade cost

db2rest is licensed under Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved. That is a permissive licence with no copyleft obligation on your own code. It is not legal advice; if you redistribute the jar inside a product, have counsel confirm the notice requirements.

On maintenance, the release history is the useful signal. The 1.6.8 line was published on 2025-12-21, with an RC on the same day and a SNAPSHOT four days earlier. The most recent push to the repository was on 2026-09-03. The repository is not archived. There is an open roadmap on db2rest.com and a separate documentation repository, db2rest-web, which means docs and code version independently; a doc page can be ahead of or behind the jar you downloaded.

Upgrade cost is dominated by the schema-as-contract property. A db2rest upgrade changes the runtime, but a schema migration changes your API. Plan column renames and type changes the way you would plan a breaking API version, because that is what they are. The Oracle 9i split at 1.2.3 is the one case where an upgrade is not simply a version bump.

Editorial conclusion

Adopt db2rest when you want read and write REST access to a relational database without writing controllers, and when the schema can be the public contract. Skip it if you need a hand-shaped API with business rules in the middle, or if you cannot grant the process broad table access. Before rollout, verify three things: that your database appears in the supported list, that the Docker image or jar version you pull matches the release you intend to run, and what the authentication module actually protects, because the README does not document the default security posture.

Frequently asked questions

Official sources

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