Bytebase — Database DevOps and CI/CD for Teams

What it is

Bytebase is an open-source database DevOps platform that sits between developers and their databases. It adds schema review, SQL linting, change-management workflows, GitOps pipelines, and fine-grained data access control to database engines that traditionally lack them.

Bytebase is built for engineering teams that want to treat database changes like code changes: reviewed, approved, and audited. It centralizes connections to 20+ engines including MySQL, Postgres, Oracle, SQL Server, Snowflake, TiDB, ClickHouse, MongoDB, and Redis.

How it saves time or tokens

Bytebase eliminates the manual back-and-forth of database change management. Instead of reviewing SQL in pull requests, pasting it into a terminal, and hoping nothing breaks, Bytebase runs 100+ built-in lint rules against your SQL, orchestrates change pipelines across dev, test, staging, and production with approval gates, and provides a full audit trail. GitOps mode triggers migrations on merge, removing manual deployment steps entirely. Data masking and query-time RBAC prevent accidental data exposure without custom middleware.

How to use

1. Start Bytebase with a single Docker container:

docker run --init --name bytebase \
  --publish 8080:8080 \
  --volume ~/.bytebase/data:/var/opt/bytebase \
  bytebase/bytebase:latest \
  --data /var/opt/bytebase --port 8080

1. Open http://localhost:8080, set up an admin account, and add your database instances.

1. Create a project, invite teammates, and submit your first schema change for review through the web UI or via GitOps by pushing a migration file to your repository.

Example

A typical Bytebase migration file stored in your Git repository:

-- Migration: Add user preferences table
-- Bytebase will lint this against 100+ rules before applying

CREATE TABLE user_preferences (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    user_id BIGINT NOT NULL,
    preference_key VARCHAR(128) NOT NULL,
    preference_value TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    UNIQUE KEY uk_user_pref (user_id, preference_key),
    FOREIGN KEY (user_id) REFERENCES users(id)
);

-- Bytebase checks: naming convention, index coverage,
-- foreign key presence, NOT NULL usage, column types

Related on TokRepo

• Database tools — More database management and migration tools curated on TokRepo.
• DevOps tools — CI/CD and infrastructure automation resources.

Common pitfalls

• Running Bytebase without connecting it to your CI/CD pipeline means changes still require manual approval clicks. Set up GitOps mode early to get the full benefit.
• Skipping the SQL lint rule configuration leads to false positives on legacy databases with non-standard naming. Customize the lint policy per project.
• Not separating environments (dev/staging/prod) in Bytebase defeats the purpose of staged rollouts. Create distinct environment configurations even if they share the same database engine.