SQLE audits SQL before it reaches the database, across MySQL, Oracle and domestic engines

The problem is the DDL window, not the query

SQLE targets a specific moment in a database team's week: the change window. A statement looks fine in review, passes whatever linter the developers happened to install, and then either locks a table for hours or drops the wrong index. The project's own framing is a four-stage loop: establish rules, control before execution, supervise after execution, and standardise releases.

What makes it more than a linter is the second and third stages. It records SQL changes with version history so a release can be diffed and, in the enterprise description, rolled back with a generated backup. It also collects SQL from slow logs and from application source code, then keeps 24 hour monitoring on execution plans, index suggestions and deadlock causes.

That scope is why the project is a platform rather than a library. It has its own web workbench with a SQL editor and completion, approval workflows with configurable levels, and notifications pushed into Feishu, DingTalk and WeCom. None of that is a shell command you run once.

The engine coverage is the other reason to look. Alongside MySQL, PostgreSQL and Oracle, the README names OceanBase, Dameng, TDSQL, GoldenDB and ActionDB as deeply adapted, and the project topic list carries both `mssql` and `pg`. The Go module pulls in the drivers that back this: go-sql-driver/mysql, lib/pq, denisenkom/go-mssqldb, and the bwmarrin/snowflake package, alongside a cloud SDK set covering Alibaba RDS, Baidu BCE and Tencent.

More than a thousand rules, and where they come from

The rule library is the product. The README states it holds over a thousand built-in rules and supports custom rule extensions, organised by intent: performance optimisation, security protection, and compliance review. It attributes the defaults to database experts at large enterprises across several industries, which is a claim about provenance rather than a technical fact, but it does explain why the rule set skews towards what breaks production rather than what is stylistically unusual.

The consequences of a rule firing are visible in the workflow. A statement that fails a rule goes into an approval queue rather than being rejected outright, and the README describes support for custom approval levels and automated strategies so a team can decide which categories of finding need a human and which can pass.

Source-level collection is the other differentiator. `go.mod` includes `github.com/actiontech/mybatis-mapper-2-sql`, `github.com/actiontech/java-sql-extractor`, and `github.com/DATA-DOG/go-sqlmock`. Alongside the README's description of application-code collection, these dependencies support the project's code-oriented SQL workflow.

Three editions, and the line between them is not in the README

SQLE is distributed in three shapes, and this is the first thing to settle before anything else. The community edition can be deployed locally or tried in a hosted demo. The professional edition requires filling in a questionnaire to obtain an installation package. The enterprise edition is demo or commercial-contact only. The README links a comparison page for the differences but does not summarise them.

That gap matters, because the feature list in the README mixes both. Rules, workflow configuration and IM notifications appear alongside backup and rollback, execution plan comparison and slow-log collection. You cannot tell from the repository front page which of those a self-installed build gives you. Plan on reading the comparison documentation, or on talking to the vendor, before you design a rollout around backup-and-rollback.

The demo environments are a reasonable way to see the interface before installing anything. The README lists separate hosted demos for the community and enterprise editions and warns that the service is for evaluation only, that its data is cleared periodically, and that it must not be used in production.

Four deployment routes and a vendored Go build

For a first look the README recommends Docker or docker-compose, and it publishes a docker image reference on Docker Hub for the community edition. Four routes are documented, each with its own page: building from source, RPM, Docker, and Docker Compose. Configuration starts from `config.yaml.template` in the repository root.

The source build is a plain Go module with a Makefile, and two details in it tell you what to expect. The module requires Go 1.24.0, and the build flags pass `-mod=vendor`, so the repository carries its `vendor/` directory and the build does not reach the network. Version stamping is derived from git: the Makefile resolves the tag pointing at HEAD, prefers a stable tag over one with a `-pre` suffix, and produces a version string such as `4.2609.0-ce` for the community edition, appending an `EDITION` variable to the release name.

The same Makefile targets `GOOS=linux`, an RPM user group named `actiontech` and an RPM user named `actiontech-universe`, with `OS_VERSION` set to `el7`. That is an Enterprise Linux 7 baseline, worth checking against your own distribution before you assume an RPM builds on it.

A `jdk/` directory sits at the repository root, alongside `scripts/` and `scspell.py` with a `spelling_dict.txt`, and a `.pr_agent.toml` for an automated pull request reviewer. The `example/db_plugin/` directory is the extension point: database support is added as a plugin, and the plugin development manual is published separately from the main documentation site.

Where SQLE loses to a plain review rule set

There are situations where a platform of this size is the wrong answer.

The clearest one is a single-team, single-engine shop. If your SQL only ever reaches PostgreSQL and your releases go through one pipeline, a handful of linter rules in CI plus a review checklist covers the same ground with no server to run, no database to connect to and no version to upgrade. SQLE's cost is a running service with its own storage, its own release train and its own failure modes.

Second, the post-execution half of the product. Execution plan comparison, deadlock root-cause analysis and slow-log harvesting all need read access to production. Handing a tool that reads production query history to a new component is a decision with security review attached, and it is not the decision you make while evaluating a pre-commit hook.

Third, editions. If the features your process depends on live in the professional or enterprise build, the open repository alone is not enough to deliver the workflow, and the migration path between editions is something the README does not describe.

For pure SQL linting without the platform, the honest alternative is a parser-level linter run in CI: it produces a machine-readable report, fails the build on a rule, and stores its results in the repository history. You give up workflow, history and production monitoring. In exchange there is nothing to host.

MPL-2.0 for the platform, a separate licence for add-ons

The repository declares MPL-2.0, and it carries a second file, `Add-On-LICENSE`, that applies to the add-on components rather than the platform itself. If you plan to modify SQLE and ship the change, read both: modified MPL-covered files must be made available under the MPL, while the add-on terms are a separate question.

This is not legal advice, and the practical takeaway is narrower. SQLE is a server application with plugins, not a library you import, so copyleft at the file level is unlikely to reach code that merely talks to it over its API. If you intend to fork the platform itself, the add-on licence deserves a proper review, because that is the part most likely to differ from the platform terms.

On cadence, the repository is not archived and the last push was on 2026-09-30. Recent tags show v4.2609.0 on the same date, v4.2608.0 on 2026-09-03 and v4.2606.0 on 2026-07-03. Two of the three most recent releases were published as untagged commit identifiers in the release list, so the tagging practice is not perfectly consistent, which matters if you script your own upgrade detection. The README describes weekly releases and rapid iteration.

Editorial conclusion

SQLE fits teams that keep losing production time to bad DDL and unindexed queries and want the check inside the release workflow rather than in a code review comment, and it is the only edition family in this project where the community build is the one you can install yourself. Do not expect the community edition to cover the audit, monitoring and approval-workflow features described in the README, because the comparison page is what separates them and the README does not spell out the line. Before committing, open one real production-shaped change set in a trial environment and count how many of the project rules fire on your existing SQL, then confirm which of your database engines appear in the supported list rather than assuming coverage.

Frequently asked questions

Official sources

1. actiontech/sqle on GitHub
2. Issues
3. License: MPL-2.0
4. README
5. Releases