Best Practices 📘

Onboarding Phases#

For Enterprise customers, we guarantee 100% implementation success in 90 days. Contact us to discuss your specific requirements.

The ultimate goal is to make Bytebase the only tool to manage all human-to-db operations. It's fine if your team has existing tooling and process. Bytebase can be adopted in phases to improve the database operational practices gradually:

Standardize ad-hoc change process (2 weeks)
Centralize data query access (2 weeks)
Integrate SQL review into CI (1 week)
Manage schema migration (4 ~ 8 weeks)

Phase 1 - Standardize ad-hoc change process#


Duration	2 weeks
Goals	1. Remove direct human write access to database. 2. Streamlined change process with review, check, rollout, rollback, notification, and history.

Manage one-off DML changes (e.g. INSERT/UPDATE/DELETE) and out-of-band schema changes (e.g. add an index on emergency).

Related features:

Phase 2 - Centralize data query access#


Duration	2 weeks
Goals	1. Remove direct human read access to database. 2. Access grants are reviewed and recorded. 3. Dynamic masking policy depending on the querier.

Bytebase provides a web-based SQL Editor.

Related features:

Phase 3 - Integrate SQL review into CI#


Duration	1 week
Goals	1. Auto check SQL anti-patterns during CI. 2. Non-intrusive to the existing CI pipeline.

If your team has the existing database schema migration process in place. You can start by including the SQL Review check into the CI.

Related features:

Phase 4 - Manage schema migration#


Duration	4 ~ 8 weeks
Goals	1. Decouple schema migration from code release. 2. Streamlined change process with review, check, rollout, rollback, notification, and history.

You have achieved decent success in implementing Bytebase for your org. You may not need phase 4 if the application is OK to deploy schema migration together with the code release. On the other hand, it's beneficial to use Bytebase for schema migration if you have any of the following situations:

Multiple servers connecting to the same database.
Multi-region database deployment.
Multi-tenant service and each tenant has its own database.
Long-running schema migration.

The implementation duration depends on how many existing schema migration workflows need to be moved to Bytebase.

Related features (in addition to Phase 1):

How to Organize Projects#

Bytebase has a Project concept to group logically related Databases, Issues and Users together. This is similar to the project concept in other tools such as Jira, GitLab.

We recommend you to put databases sharing the same schema structure into the same project. For example, if you have a multi-tenant SaaS application, you can put all the tenant databases into the same project.

If you have a single team managing databases with different schema structure, you can create a project for each schema structure, and create a user group for the team. You then grant the project role to the user group.

Configuration Guideline#

Bytebase provides settings at the workspace, environment, project levels. Below we provide a sample configuration settings for a typical scenarios:

Three environments Dev, UAT, Prod.
Dev does not enforce any review and access control.
UAT enforces limited review and access control.
Prod enforces strict review and access control.

		Dev	UAT	Prod
Environment tier	Environment color	Black	Yellow	Red
	Production indicator	❌	❌	✅
Statement execution mode	Allow running DDL in SQL Editor	✅	❌	❌
	Allow running data-modifying DML in SQL Editor	✅	❌	❌
Database CI/CD	Approval Policy	No approver	Single approver	Multiple approvers
	Rollout Policy	Automatic	Manual	Manual
Database Permission	EXPLAIN	✅	✅	✅
	Query	✅	✅	Approval at db/table level
	Export	✅	✅	Approval at db/table level
Data masking		❌	❌	✅

Edit this page on GitHub