Govern production database changes
Production database changes should be reviewed, traceable, and aligned with team standards. NineData Database DevOps helps teams centralize data source access, enforce SQL development policies, and route high-risk changes through approval workflows before execution.
Why Change Governance Matters
Without a controlled workflow, production changes often rely on direct database connections, shared accounts, chat messages, or ticket handoffs. This creates several risks:
- Teams cannot reliably identify who executed a SQL statement.
- Developers may run DDL or DML directly in production.
- Naming, schema, and SQL standards are hard to enforce.
- Permission changes caused by onboarding, role changes, or employee departures are difficult to maintain.
- Incident review becomes slow because execution records are scattered across tools.
Recommended Control Model
Use NineData to build a governed database change workflow:
- Add production data sources to NineData and manage access from one platform.
- Assign a data source owner so approval routing can follow business ownership.
- Configure SQL development policies for development and production environments.
- Disable direct production changes in SQL Console when changes must go through SQL tasks.
- Configure approval workflows for SQL tasks.
- Use task details and audit records to trace review and execution history.
Prerequisites
Before you configure the workflow, make sure that:
- Production data sources have been added to NineData.
- Each data source is assigned to the correct environment.
- Administrators have permission to manage SQL development policies and approval processes.
- The team has defined who should approve production changes.
Configure The Workflow
1. Add Production Data Sources
Add each production data source to NineData. After a data source is created, the creator becomes the default owner. The owner can later be used in approval routing.
2. Configure Development Standards And Approval Processes
NineData provides default standards and processes for development and production environments. Each data source is bound to the standards and process of its selected environment.
If the default configuration does not match your governance model, update the policy and approval process. The example below disables SQL Console changes for production databases and configures a two-level approval process.
3. Disable Direct Production Changes In SQL Console
Open the SQL development policy that applies to the production environment. Edit the rules that control SQL Console DML and DDL operations, and remove the allowed operation types.
| Rule Name | Switch | Edit Details |
|---|---|---|
| Allowed SQL Console Update Data Type | On | In the Actions column, select Edit, find Allowed SQL Console Update Data, remove all operation types, and select OK. |
| Allowed SQL Console Update Structure Operate Type | On | In the Actions column, select Edit, find SQL Console Allowed Type, remove all operation types, and select OK. |
4. Configure A Two-Level Approval Process
Open the approval process that applies to production SQL tasks. Add the approval levels and select the approvers.
In this example, a developer can submit an SQL task only after the SQL passes the standard precheck. The task then requires first-level and second-level approval before execution.
For the first-level approver, you can use Data Source Owner instead of selecting a fixed person. When a user submits a task for a specific data source or database, NineData resolves the owner of that data source or database and routes the approval accordingly. This reduces approval-process maintenance when business owners change.
Validate The Workflow
Confirm that direct DDL and DML operations are blocked in SQL Console for ordinary users. The console guides users to create an SQL task instead.
Submit an SQL task. NineData checks the SQL against the configured standards, then requests the required approvers.
After approval, the selected executor runs the SQL task. If automatic execution is enabled, NineData executes the task after the final approval.
Use SQL Console or task details to verify the execution result.
Result
Production database changes now follow a controlled workflow. Users cannot bypass the configured SQL policy, approvals are recorded in the SQL task, and execution history can be reviewed during audits or incident analysis.