Yearning: a self-hosted MySQL SQL audit platform with approval tickets and rollback generation

The problem Yearning solves: hand-written MySQL with no approval trail

Most teams that run MySQL end up with the same gap. Developers have production credentials or a jump host, and schema changes arrive as pasted SQL in a chat thread. Nobody records who approved the statement, what it touched, or how to undo it. Yearning targets exactly that gap. The README describes it as a locally deployed platform for SQL detection and query auditing, aimed at DBAs and developers. Two audiences, two different jobs. The DBA gets a queue of tickets with rules applied before anything reaches the server. The developer gets a web editor with syntax highlighting and auto-completion instead of a terminal.

The privacy angle is the reason to choose it over a hosted service. The README states the project is locally deployable and open source, and that it includes encryption mechanisms to protect sensitive data even if unauthorized access occurs. For a company that treats production SQL as confidential, sending statements to a vendor's API is a non-starter. Yearning keeps the statements inside your network, with the AI assistant as the one component that can call an external model.

It is not a migration framework. It does not diff your schema, generate versioned migration files, or run on every deploy. It is a workflow layer that sits in front of MySQL and decides whether a statement is allowed through.

How Yearning works: tickets, check rules, RBAC and query records

The core loop is a work order. A user submits SQL as an audit ticket. The ticket passes through an approval workflow and an automated syntax check, and the README says rollback statements are generated automatically for DDL and DML operations. That last detail is the part worth pausing on. Generating a rollback for a DDL statement means the platform has to read the current schema before the change lands, so the ticket flow implies a connection to the target data source at review time, not only at execution time.

Around that loop sit three supporting pieces. Check rules are the automated syntax checker, described as supporting a range of rules suitable for most automatic checking scenarios. RBAC lets you create roles and restrict access to query work orders and auditing functions by role. Query audit covers read traffic: restrict data sources and databases, anonymize sensitive fields, and keep query records for later reference.

The repository layout matches this description. There is a cmd/ directory for the binary's subcommands, a migration/ directory, a src/ tree, and a conf.toml.template at the top level. The Go module list is short and readable: gorm with the MySQL driver for persistence, go-ldap for directory authentication, golang-jwt for tokens, robfig/cron for scheduled work, and go-openai for the AI assistant. LDAP support matters for enterprises that do not want a second password store. The cron dependency implies scheduled tasks, though the README does not enumerate them.

The AI assistant is optional infrastructure, not a core mechanism. The README says it uses a large language model for optimization suggestions and text-to-SQL conversion, with default or custom prompts. In an air-gapped deployment that feature is simply unavailable unless you point it at something reachable.

Installing Yearning and submitting a first audit ticket

The README gives two paths: a release binary and a Docker image. For the binary, download the latest release and extract it, then configure ./config.toml before proceeding. Note the filename mismatch in the repository: the template at the top level is conf.toml.template, while the README refers to ./config.toml. Check which name your extracted release actually contains before running the install step.

The manual sequence is three commands. The first initializes the database, the second starts the service, and the third prints help.

./Yearning install
./Yearning run
./Yearning --help

The Docker path splits the same work across two containers, one to initialize and one to run detached. The image is yeelabs/yearning and the service listens on port 8000. Every environment variable below is copied from the README: SECRET_KEY, MYSQL_USER, MYSQL_ADDR, MYSQL_PASSWORD, MYSQL_DB, and Y_LANG.

docker run --rm -it -p8000:8000 -e SECRET_KEY=$SECRET_KEY -e MYSQL_USER=$MYSQL_USER -e MYSQL_ADDR=$MYSQL_ADDR -e MYSQL_PASSWORD=$MYSQL_PASSWORD -e MYSQL_DB=$Yearning_DB -e Y_LANG=zh_CN yeelabs/yearning "/opt/Yearning install"

The first container exits when initialization finishes, which is why it uses --rm and no -d. The second run drops the install argument and adds -d so the service stays up.

docker run -d -it -p8000:8000 -e SECRET_KEY=$SECRET_KEY -e MYSQL_USER=$MYSQL_USER -e MYSQL_ADDR=$MYSQL_ADDR -e MYSQL_PASSWORD=$MYSQL_PASSWORD -e MYSQL_DB=$Yearning_DB -e Y_LANG=zh_CN yeelabs/yearning

After that, open port 8000 in a browser. The README does not state the default administrator credentials, so treat first-login setup as something to confirm against the Yearning Guide at next.yearning.io before you expose the port. Once inside, add a data source, then create an audit ticket with a DDL statement. The expected result is a ticket in a pending state with a generated rollback statement attached and the check rules already applied. If the rollback field is empty, the check rules or the data source connection are the first things to inspect.

Where Yearning is the wrong tool

Yearning is MySQL-only. The README, the topics list, and the module dependencies all point at a single engine, with go-sql-driver/mysql as the only database driver in the direct dependency list. If your estate includes PostgreSQL, SQL Server, or a managed warehouse, this platform will not audit them, and you should not expect the check rules to transfer.

The second limitation is architectural. The platform needs its own MySQL instance for metadata, separate from the databases it audits. That is a service to back up, upgrade, and monitor. A team of two with a single small database may find that overhead larger than the problem it solves.

The third is workflow fit. If your schema changes already go through a migration tool that runs in CI with review on the pull request, a ticket queue duplicates the approval step in a second system. Two places to look when someone asks why a column changed is worse than one.

The AI assistant deserves its own caution. Text-to-SQL and optimization suggestions depend on a model you configure. The README does not describe which providers are supported beyond the presence of the go-openai client, nor what data leaves the deployment when the feature is used. In a privacy-focused product, that is the one feature whose data flow the README leaves unexplained.

Yearning compared with migration tools and general automation platforms

The closest comparison is a migration framework such as Flyway or Liquibase. Those tools treat schema change as code: versioned files in the repository, applied in order, with a history table in the database. Approval happens on the pull request, and the tool is the only writer. Yearning inverts this. The statement is the artifact, approval happens inside Yearning, and the platform is the gate rather than the applier. Migration tools fit teams that deploy often and want the database to move with the code. Yearning fits teams where a DBA reviews changes by hand and needs a record of that review.

The README also lists Spug as a recommended tool, described as an open source lightweight automation operations platform. The difference is scope. Spug covers host and deployment automation broadly; Yearning covers SQL review and query control specifically. They are complementary rather than competing, and the recommendation in the README reads as an acknowledgment that Yearning does not try to be an operations platform.

The honest framing is that Yearning is a governance product. Its value scales with the number of people who can reach production MySQL and the cost of an unreviewed statement. On a single-developer project it is ceremony. On a team of twenty with shared credentials it is the difference between a rollback statement existing and nobody knowing how to write one.

Maintenance, releases and the AGPL-3.0 licence

The repository is not archived, and the last push to the next branch was on 2026-08-24. The most recent tagged release is v3.1.9.1 from 2024-11-10, with v3.1.9 before it on 2024-11-01 and v3.1.8 on 2024-07-27. So commits continue while tagged releases have been quiet for a while. If you deploy from tags rather than from the branch, plan for a long gap between upgrades, and check whether the branch carries fixes you need.

The upgrade cost is not documented in the README. There is a migration/ directory in the repository, which suggests schema migrations run as part of the install or run commands, but the README does not describe a rollback path or a downgrade procedure. Before upgrading in place, back up the metadata database, because that is where tickets, query records, and configuration live.

The licence is AGPL-3.0. That is a strong copyleft licence with a network clause: if you modify Yearning and let users interact with it over a network, the licence's terms reach that modified version. Running the unmodified release internally is the ordinary case. Building a commercial hosted service on top of a modified fork is where the obligation becomes significant. This is a description of the licence family, not legal advice; read the LICENSE file in the repository and talk to counsel if the network clause applies to your plans.

Editorial conclusion

Adopt Yearning if your team writes MySQL by hand and needs an approval trail plus auto-generated rollback statements, and you are willing to run the platform and its MySQL metadata store yourself. Skip it if your schema changes already flow through a migration tool in CI, since a ticket queue adds a second place for state to live. Before committing, verify what the install step creates in your target database and confirm the AGPL-3.0 terms against how you intend to expose the service.

Frequently asked questions

Official sources

1. cookieY/Yearning on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases