GoInsight: a database ticketing platform for MySQL and TiDB

The problem it names: DBA and developer working in different directions

GoInsight is an enterprise database web management platform built on Gin and Vue3, providing database ticketing and data query capabilities. The project description names the three pains it addresses directly: inefficient collaboration between DBAs and developers, high-risk operations, and missing audit trails.

That framing matters, because a database ticketing system is not a query tool with a form wrapped around it. The point of a ticket is that a request for a schema change or a data export becomes an artefact with an author, a justification, a set of approvers and an outcome. The audit trail is not an add-on feature, it is the reason the system exists.

The architecture badge tells you the shape of the thing. The backend is Gin, the frontend is Vue3, and the database is MySQL or TiDB. So the platform itself is a normal web application, and the unusual part is what it manages.

The repository layout is a standard separated frontend and backend project: a backend/ directory for the Go server, a www/ directory for the Vue frontend, docs/ and scripts/ directories, an assets/ directory, and a .codex/ directory at the root.

The licence is MIT, the releases are named GA, and the release list shows v2.1.0 on 2026-03-04, v2.0.2 on 2026-01-09 and v2.0.1 on 2026-01-05. The last push to the repository was on 2026-04-04, and the repository is not archived.

The project also has a public wiki of screenshots, which for an interface-heavy platform like this is a reasonable way to see the workflows without installing it.

The module table, read as a description of a DBA's day

The core module table lists seven areas, and reading them in order describes the workflow of a change request from beginning to end.

Ticket management is the first, and it supports DDL, DML and data export tickets with CSV or XLSX output. It supports approval, execution, rollback and one-click copying of a ticket, which is the last one being the quietly useful feature: a ticket you have already had approved can be reused rather than re-approving a similar statement.

The approval flow module supports countersignature and or-signature, so one or all of several approvers must sign, and it allows customising the approval flow and hierarchy according to the organisation structure. That is a deliberate design choice. A fixed two-step approval is a toy; the ability to say that a change to the payroll table needs three sign-offs and a change to a log table needs none is what makes a ticketing system fit an actual organisation.

SQL audit comes next, and it is the most specific feature in the list: a built-in high-performance syntax auditor supporting 68 audit rules, with global and instance-level parameter configuration. The instance-level part is the interesting bit, because it means the rule set can differ between a test instance and a production instance, which is where the risk difference actually is.

Data query supports library and table level access control and query auditing. Permissions and permissions are separate features, and both matter: who can see which table, and a record of what was read.

Then permission and organisation, which is based on the organisation structure for user and role management, with DB instances bound to the organisation to achieve access isolation. That last phrase is the security model stated plainly: a team bound to an instance cannot reach an instance belonging to another team.

Environment isolation supports custom multiple ticket environments such as test, staging and production, ensuring the change release process is standardised.

Message notification integrates DingTalk, WeCom and email push, and the catch-all row is two-factor authentication support.

MySQL and TiDB, and the one difference that changes the workflow

The supported database table is short, and one difference in it is worth understanding before you pick a database for the platform itself.

MySQL and cloud services require version 5.7 or newer, and support DML tickets including rollback, Online DDL through gh-ost, encrypted data export, and library and table level permission control for data queries.

TiDB requires version 4.0 or newer. It supports DML tickets, but does not support generating rollback SQL, and it has native Online DDL rather than the gh-ost route, along with the same encrypted export and the same query permissions.

The rollback difference is the one that changes how the platform is used rather than just how it is configured. A DML ticket on MySQL can be reversed, because the platform can generate the compensating statement. On TiDB it cannot, because there is no equivalent of the gh-ost based online schema change to hang the rollback on.

So on TiDB, a destructive data change is a one-way door through the ticketing system, and the approval workflow has to carry more of the weight. That is not a defect so much as a property of the database, but it means the two supported engines give you clearly different safety guarantees, and the documentation is right to put it in a table rather than a footnote.

The native Online DDL on TiDB is the corresponding upside: no external migration tool is needed, so the platform does not have to orchestrate a gh-ost run against that engine.

Deploying it, and the default credentials you must change first

Deployment is a binary and a config file, and the guide is three steps.

First, download the binary package. Go to the Releases page and get the latest installer package. Second, start the service:

./goinsight-linux-amd64 -config config.yaml

Third, open it in a browser at the address and port from your config, where the default administrator is admin with a default password that the guide spells out.

The security note attached to that step is the part to take seriously. The guide says to change the password immediately after the first login, and strongly recommends deploying Nginx in front of GoInsight with an HTTPS reverse proxy in a production environment.

That recommendation is not boilerplate here, and the reason is in the module list. This application holds database credentials for MySQL and TiDB instances, it can execute DDL and DML against production databases on approval, it can export data to CSV or XLSX files, and it exposes a data query console. A plaintext HTTP endpoint in front of that is a much bigger problem than the same endpoint in front of an ordinary internal tool.

The exported files are worth a second thought for the same reason. A ticket that exports a table to a spreadsheet is a ticket that moves production data into a file that is then emailed around, and the notification integrations push to chat tools and email. The environment isolation feature, with separate test, staging and production ticket environments, is what keeps a request for one of those exports from being run against production by mistake.

What to check before you adopt it, and where the gaps are

The documentation is a README with a module table, a database table, a deployment section and a screenshot wiki. That is enough to evaluate the shape of the product and not much more, and it is worth knowing where the answers are not.

The project states its supported database engines and their version floors, which is unusually good practice, and it states the feature set precisely enough to be testable. What it does not state is anything about the audit rules themselves. There are 68 of them, and they are described as a high-performance syntax auditor with global and instance-level configuration, but the list of rules is not in the repository. For a system whose job is to block a dangerous statement, the rule list is the substance, and you would want to see it before deciding whether 68 is enough for your environment.

The approval flow is similarly described by capability, countersignature and or-signature, customisable by organisation structure, without an example of a configured flow. That is a gap in the documentation rather than in the product, but it means you will be learning the configuration model from the running system.

There is also a practical question about the platform's own database. The system stores its tickets, approvals, query logs and audit records somewhere, and the deployment step is a single binary with a config file, so that store is configured in the same file. The README does not discuss the retention of that history, which for an audit system is not a trivial decision.

The contact and support section is modest: issues and pull requests are welcome, with an email address and a WeChat contact. There is no stated support commitment, so for a platform that ends up in the path of a production change, that is worth raising before deployment rather than after.

The other thing to notice is the pace. The last push was on 2026-04-04 and the most recent release v2.1.0 came on 2026-03-04, so check the release notes for the version you plan to run rather than assuming the newest tag reflects the current tree.

Editorial conclusion

Adopt GoInsight if your organisation already has a DBA gate around schema changes and a need to record it, since the approval chain, the audit rules and the query log are the features that make it more than a SQL client with a form in front of it. Do not adopt it expecting it to replace your database's own privilege model, because the permissions it enforces are at the table level within the application, not in the server. Before you deploy, change the default administrator password, and put it behind Nginx with HTTPS as the documentation recommends, since the application is designed to sit on a network path to production databases.

Frequently asked questions

Official sources

1. Issues
2. lazzyfu/goInsight on GitHub
3. License: MIT
4. README
5. Releases