DBAPI: a low-code service that turns SQL into HTTP endpoints with a governance layer

The premise is that SQL is the API

DBAPI is a low-code data service platform for data warehouse developers, and its premise is in the tagline: write SQL and configure parameters on the page, and it automatically generates production-grade HTTP API endpoints.

The positioning is described as an enterprise data service management centre, centrally managing, publishing, monitoring and governing all data APIs. The named scenarios are BI reports, data dashboards, rapid frontend prototyping and AI application data integration, and the stated philosophy is that SQL is the API.

That is a real and specific trade. Instead of a controller, a DTO layer and a service class for every report, you write a query, bind parameters to it, and the platform produces the endpoint. The benefit is speed for the case where the consumer is a dashboard that needs some rows. The cost is that the contract is derived from the query, so a dashboard that needs a stable, documented shape is not served well by it.

The repository is small for what the platform does. The top level holds a .gitignore, the LICENSE, the English and Chinese READMEs, a data.db file, a pom.xml and a src directory. The presence of a data.db at the root tells you the default is an embedded database, and the badges show two editions, Community at 4.0.32 and Enterprise at 4.6.0, with a JDK 8, 11 or 17 badge and a licence badge reading Community Free. The licence field on the repository says AGPL-3.0.

Data sources, dynamic SQL and the editor

The data source coverage is the widest part of the feature list. For relational databases it names MySQL, SQL Server, PostgreSQL, Oracle, Hive, DM, Kingbase, Doris, OceanBase and GaussDB, and claims support for all JDBC-compatible databases. Alongside that there is an ES DSL executor for running Elasticsearch queries directly, and an HTTP executor for forwarding third-party REST APIs.

The SQL layer is described as dynamic and MyBatis-style, supporting both the #{} and ${} parameter binding forms and the full MyBatis dynamic SQL syntax, which is the difference between a parameterised value and a substituted fragment, and the difference between a safe API and an injection hole depending on which one you bind.

There is a SQL editor with built-in run and debug described as WYSIWYG, support for Select, Insert, Update and Delete as well as stored procedures, and multi-SQL combined execution with flexible transaction control.

The plugin system is organised into five categories, and each one is a hook rather than a feature you use directly. Cache plugins cover Redis, Ehcache and Elasticsearch, data transformation plugins do masking and format restructuring, alert plugins cover email, SMS, DingTalk, Feishu and WeCom, parameter processing plugins handle decryption, validation and transformation, and global data transformation plugins are compatible with AMIS and other frontend frameworks.

So the extension model is a plugin catalogue rather than a code-first framework, and the built-in points cover the things that vary between deployments: caching, masking, alerting and parameter handling.

The governance layer is the actual product

The security table is where this stops being a SQL-to-HTTP translator.

Dynamic auth uses a clientId and a secret to obtain a token, with API-level access control on top. An IP firewall does whitelist and blacklist filtering. Rate limiting applies QPS throttling at the API level. Data encryption applies RSA encryption to response data and a digital signature to request parameters. Audit logging gives a full operation audit trail.

Any one of these is a feature you would otherwise write. Having them at the platform level means a dashboard team publishes an endpoint and inherits the controls, which is the argument for a management centre rather than a per-project service.

The monitoring section is what makes it operable rather than merely functional. There is API call history query and access statistics, and log storage can go to ClickHouse, MySQL, PostgreSQL or Doris, with a Kafka buffer collection for large-scale scenarios. That Kafka option is a scale signal: a log sink behind a message buffer implies the call volume is expected to be large enough that writing synchronously to a database would be the bottleneck.

The remaining capabilities are about changing things safely. APIs can be created, modified and deactivated dynamically with zero-downtime hot deployment, there are built-in API variables __clientId and __apiId, there is an OpenAPI interface for system integration, and there are data source health checks with preset request test parameters. API group management, import and export, and version rollback are marked as Enterprise.

Orchestration, MCP mapping and the AI angle

API orchestration is the feature that turns a set of endpoints into a workflow. There is a DAG visual canvas with drag-and-drop orchestration and no coding required, supporting Start, then API Execution, then Condition with If and Else nodes, then End nodes. The previous API's results feed directly into subsequent steps, and Groovy script processing is available for flexible data handling.

Groovy in the middle of a request path is a significant choice. It gives you arbitrary transformation logic without waiting for a deploy of the platform, and it also means a user with canvas access can execute code on the server. That is worth thinking about before you open the platform to more people.

The AI support is described as mapping DBAPI data APIs to MCP tools, integrating with Claude Desktop, Cursor, LangChain, Spring AI and other AI clients, and an AI assistant that generates SQL from natural language. MCP mapping is the interesting piece, because it means the endpoints you already publish for dashboards become tools an agent can call, without a second integration layer.

The natural language to SQL feature is the one to be most careful with. Generating a query and running it against a warehouse means the model is writing to your database, and the same parameter binding discipline that mattered for the manual SQL editor matters more here. The documentation does not describe any guardrails for that path, so it is worth assuming the safe defaults are not assumed for you.

Installing and running the Community edition

The prerequisites are JDK 8, 11 or 17, and OpenSSL 3, which is not required on Windows. The install is a download and extract:

# Download Community Edition (free)
wget https://img.51dbapi.com/dbapi/dbapi-4.0.32-bin.tar.gz
tar -xzf dbapi-4.0.32-bin.tar.gz
cd dbapi-4.0.32

# Modify database config (default uses embedded SQLite)
# vim conf/application.properties

# Start service
bash bin/dbapi-daemon.sh start standalone

The service then answers on port 8520, and the default credentials are admin and admin. The script takes a mode argument, and the example uses standalone, matching the claim that the platform supports standalone and cluster mode on Windows and Linux.

The deployment claims are modest and worth noting. The platform says it needs no coding and no external dependencies beyond a Java runtime, and that it runs stably on a 2-core 4GB server. Those two together mean you can try it on a laptop before deciding anything, which is the right way to evaluate a tool this broad.

A live demo is available at the project site with the same admin and admin credentials, and there is a Chinese documentation site as well as the English one, with a separate installation guide linked from the quick start.

Where DBAPI is the wrong choice

The first limitation is that the API contract follows the query. A generated endpoint shaped like its SQL is convenient for a report and awkward for a consumer that needs a stable, documented, versioned interface, and a dashboard team that keeps changing the query will keep changing the contract without anyone deciding to. The Enterprise version's API group management and version rollback exist because that problem is real, and they are not in the free edition.

The second is the operational surface. Five plugin categories, an orchestration canvas with Groovy execution, MCP mapping, an AI assistant that writes SQL, hot deployment, and a choice of four log stores plus a Kafka path is a lot of machinery for a tool whose pitch is that you write SQL and stop coding. Teams that adopt it end up running a platform with its own plugins, its own DAG definitions, its own API groups and its own log pipeline, and that is a system to own rather than a tool to use.

The third is the licence. AGPL-3.0 with a Community edition marked free and an Enterprise edition sold separately, and the repository is the Community part with the enterprise features marked in the feature list. If your data service is internal to your company, AGPL is usually workable, but if you intend to expose the generated APIs to people outside your organisation, the obligations of the copyleft licence and the boundary between the two editions both need a legal answer before you build on it.

The honest comparison is with writing the endpoint yourself. For a handful of internal reports, a small service with a query and a documented response is faster to reason about and easier to change than a platform, and it has no plugin surface to keep current. DBAPI pays for itself when the number of endpoints is large enough that the per-endpoint cost dominates, the consumers are many dashboards rather than one application, and the governance features are wanted for their own sake rather than as a way to avoid writing CRUD.

Editorial conclusion

DBAPI fits a data warehouse team that has many internal dashboards and reports to wire up, and that wants one governed place to publish read endpoints from SQL rather than a bespoke service per report. It does not fit a team that wants a public API with a designed contract, since the generated endpoints follow the queries rather than a schema you designed. Before deploying it, read the security section in the documentation rather than the feature list, change the default admin credentials, decide where the audit log and the call history live, and check which of the listed database and plugin integrations your stack actually needs, because the compatibility claims are broad and the free edition is a smaller subset than the enterprise one.

Frequently asked questions

Official sources

1. freakchick/DBAPI on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README