Compare SQL Server data masking options — native Dynamic Data Masking (five mask types, SQL Server 2022 granular UNMASK) and Bytebase fleet-wide masking.

SQL Server Dynamic Data Masking

Compare Oracle data masking options — native Data Redaction (five function types via DBMS_REDACT, EXEMPT REDACTION POLICY) and Bytebase fleet-wide masking.

Oracle Dynamic Data Masking

You write a one-line UPDATE against production. Here's the lane that keeps it safe — the four phases, the controls, and what each one prevents.

How to Handle Ad-hoc Database Data Changes?

Notes on the MySQL 9.7 LTS release: Hypergraph Optimizer in Community, JSON Duality View DML, Group Replication observability, and Dynamic Data Masking for Enterprise.

Notes on the MySQL 9.7 LTS release

Most DAC implementations stop at the connection. Real DAC operates at the statement and covers three vectors: machine, human, and AI agent.

What is Database Access Control (DAC)?

Practical guide to dynamic data masking: five best practices, a vendor comparison, an end-to-end walkthrough, and the compliance specifics auditors ask about.

Dynamic Data Masking Best Practices

How Bytebase audits the workflow layer: every SQL, schema change, approval, and export tied to a real user identity, with structured exports for any SIEM.

How Bytebase Handles Audit Logging

PostgreSQL 19 features I'm excited about: planner advisor framework, DDL extraction, online REPACK, pg_stat_recovery, parallel autovacuum, sequence sync, and 64-bit MultiXact.

PostgreSQL 19 features I'm excited about

Bytebase is HIPAA-compliant — independent verification that our administrative, physical, and technical safeguards meet the HIPAA Security Rule for handling Protected Health Information.

HIPAA Compliance

PAM tools gate connections; databases also need SQL review, schema change workflow, and statement-level approval. Why most teams use PAM with Bytebase.

Bytebase vs. PAM: Why Database Teams Need More Than Privileged Access Management

What SOC 2 compliance audits actually want from your database audit log — not 'logging enabled' but evidence your auditor will accept. Lessons from going through our own audit.

SOC 2 Audit Log Requirements: Lessons From Our Own Audit

Bytebase vs. Atlas compared across migration approach, CI/CD, access control, and pricing. Updated for Atlas v1.1 and Bytebase 3.16.

Bytebase vs. Atlas: a side-by-side comparison for database schema migration

Audit-surviving database access control: statement-level enforcement across machine, human, and AI agent workloads, with the mistakes that fail SOC 2.

Database Access Control (DAC) Best Practices

SOX Section 404 requires IT general controls over database changes. Learn the ITGC domains, six audit questions teams fail, and how to build SOX-ready controls

Database Change Management for SOX Compliance

TRUNCATE and DELETE both remove rows, but they differ in speed, rollback behavior, and locking. Compare how they work in PostgreSQL, MySQL, and SQL Server.

TRUNCATE vs DELETE in SQL: Differences Across PostgreSQL, MySQL, and SQL Server

Six database design patterns for production systems: normalization, star schema, EAV, polymorphic associations, multi-tenancy, and anti-patterns.

Database Design Patterns Every Developer Should Know

pgvector adds vector storage and similarity search to PostgreSQL. Learn how to install it, query embeddings, build indexes, and decide when it is enough.

pgvector: How to Add Vector Search to PostgreSQL

Upsert inserts or updates a row based on key conflicts. Learn MySQL INSERT ON DUPLICATE KEY UPDATE, PostgreSQL ON CONFLICT, and SQL Server MERGE.

Upsert in SQL: INSERT ON DUPLICATE KEY vs ON CONFLICT Explained

AI agents need more than DDL. The full database lifecycle codified — schema, dependencies, ownership, history — gives LLMs the context to query correctly.

From Schema as Code to Schema as Context

Learn how to find and fix slow MySQL queries using the slow query log, EXPLAIN, index tuning, and query rewrites, with practical examples for each.

How to Fix Slow MySQL Queries: A Practical Guide

A detailed comparison of Convex and Supabase covering architecture, real-time capabilities, data model, pricing, and schema management to help you choose.

Convex vs Supabase: Which Backend Platform Should You Choose?

Blue-green deployments work cleanly for stateless apps. Databases are stateful. Learn what makes database blue-green deployments hard and how to do them safely.

Database Blue-Green Deployment: A Practical Guide

The 10 best data management tools in 2026 — database GUI clients, schema migration tools, data pipelines, and analytics platforms compared with pricing.

Top 10 Data Management Tools in 2026

How to give AI agents governed access to your databases. Identity, authorization, query control, audit, and masking — applied to a new principal type.

How to Govern AI Agent Database Access

Postgres-only SQL editors are designed specifically for Postgres databases, providing a more focused and efficient experience for Postgres users. In this post, we are taking a look at the top Postgres-only SQL editors in 2026.

Enterprise Text-to-SQL: Context, Evaluation, and Governance

Database deployment tools for devops teams in 2026.

Database Deployment Tools for DevOps Teams in 2026

Schema change detection and notification are essential for data pipelines. This article explains why a simple column rename can break your data pipeline and how to prevent it.

Schema Change Detection and Notification: Why a Simple Column Rename Can Break Your Data Pipeline

A comprehensive guide to understanding and analyzing Postgres query plans.

Postgres Query Plan: How to Read and Fix Performance Issues

This article explores the anatomy of Postgres permissions ERROR 42501.

The Anatomy of Postgres Permission ERROR 42501

Postgres Logs Explained: A Practical Guide for Production

Postgres 19 widens MultiXactOffset to 64 bits, eliminating the hidden 4 billion member limit that caused catastrophic outages for high-concurrency workloads.

Postgres 19 Feature Preview: 64-bit MultiXactOffset

A guide to MySQL schema migration best practice.

MySQL Schema Migration Best Practice

Postgres 19 introduces automatic sequence synchronization for logical replication, eliminating manual tracking and making major version upgrades and failover significantly easier.

Postgres 19 Feature Preview: Sequence Synchronization for Logical Replication

A guide to multi-environment deployments in databases.

Database Multi-Environment Deployments - The Challenges and Patterns

A guide to open source sensitive data discovery tools — from NLP libraries like spaCy and Microsoft Presidio to multi-source scanners like Hawk-Eye and full metadata platforms like OpenMetadata.

Top Open Source Sensitive Data Discovery Tools in 2026

Database audit logging has two layers: infrastructure (provider-managed) and workflow (database activity). What each captures, and why compliance requires both.

Database Audit Logging: Two Layers, One Trail

A practical guide to HITRUST database compliance covering access control, audit logging, change management, and data protection.

Database Compliance for HITRUST: Controls, Risks, and Best Practices

Learn why requiring a primary key is important and how the "Require Primary Key" review rule protects your production database.

Require Primary Key: A SQL Review Rule Explained

Learn why enforcing NOT VALID in CHECK constraints is important and how the "Enforce NOT VALID in CHECK" review rule protects your production database.

Enforce NOT VALID in CHECK: A SQL Review Rule Explained

Postgres Audit Logging Guide

Learn why CASCADE operations in SQL can lead to catastrophic data loss and how the "Prohibit CASCADE" review rule protects your production database.

Prohibit CASCADE: A SQL Review Rule Explained

A comprehensive guide on migrating from Supabase to AWS, covering database, auth, storage, functions, realtime, and networking.

How to Migrate from Supabase to AWS

Top open-source Postgres backup solutions for 2026.

What is Enterprise Database Management (EDM)?

What is Postgres Transaction ID (XID) Wraparound and how to monitor and prevent it.

Postgres Transaction ID (XID) Wraparound

How a CI/CD pipeline for database schema migration works end-to-end — what it gates, what it leaves outside, and the tools that fit.

How to Build a CI/CD Pipeline for Database Schema Migration

A practical guide to shipping features efficiently using PostgreSQL, covering development workflows, best practices, and real-world examples

How I Ship Features with Postgres

A comprehensive overview of the essential practices and principles necessary for achieving LGPD (Brazilian General Personal Data Protection Act), compliance within database operations, and its difference with GDPR

Database Compliance for LGPD: Implications and Best Practices

Explain what is Postgres LATERAL JOIN and how to use it.

What is Postgres LATERAL JOIN?

Introduction to MySQL Online DDL and its three algorithms: INSTANT, INPLACE, and COPY

MySQL Online DDL: A Practical Guide

List of open source postgres connection poolers

Open Source Postgres Connection Pooler

A comprehensive guide to understanding the dilemma of singular vs. plural table naming in SQL databases.

SQL Table Naming Dilemma: Singular vs. Plural

PostgreSQL 18 features that change how application developers write and ship code.

What's New in PostgreSQL 18: A Developer's Perspective

Compare Snowflake Dynamic Data Masking with database views and Bytebase fleet-wide masking — edition gate, policy management, audit trail.

Snowflake Dynamic Data Masking (DDM) and Alternatives

Top open-source Postgres authentication solutions for 2025.

Postgres Case Sensitivity Explained

A comprehensive guide to understanding pg_database_owner in Postgres

What is pg_database_owner in Postgres

Which operation causes a Postgres table rewrite

Which Postgres Operation causes a table rewrite

An engineering perspective to evaluate Postgres row-level-security footguns

Postgres Row-Level Security Footguns

An engineering perspective to evaluate Postgres rollback strategies

Postgres Rollback Explained

Learn how Postgres locks affect schema migrations and which DDL operations conflict with DML to achieve zero-downtime deployments.

Postgres Schema Migration without Downtime

A checklist of gh-ost limitations and potential gotchas

gh-ost Limitations You Need to Know Before Production

5 quick wins for application developers to improve Postgres reliability and make both their own and DBA/infrastructure teams' lives easier.

5 Postgres Production Tips for Application Developers

Learn how to use CREATE INDEX CONCURRENTLY in Postgres to build indexes without blocking writes. Pitfalls, safety checks, and performance tips.

How to Use Postgres CREATE INDEX CONCURRENTLY

An extensive comparison between Supabase and MongoDB on performance, usability, operability, ecosystem and more.

Supabase vs. MongoDB: a Complete Comparison in 2025

When evaluating database management tools, DataGrip and Bytebase represent two different philosophies: individual developer productivity versus team collaboration and governance.

Bytebase vs. DataGrip: a side-by-side comparison for database management

Supabase pricing starts free. We break down real costs for Pro ($25/mo) and Team ($599/mo) plans, explain overages, and compare each service head-to-head with AWS.

Supabase vs AWS: Feature and Pricing Comparison (2026)

Is Supabase free? Compare Supabase pricing vs AWS RDS and Aurora across free tier, Pro, and production plans. Includes Supabase free tier limits, storage costs, and compute pricing for 2026.

Supabase Pricing vs AWS RDS: Is Supabase Free? Full Cost Comparison (2026)

Learn how Bytebase enables organizations to implement comprehensive Database Security Lifecycle Management, unifying security and operations from development to production.

Database Security Lifecycle Management

Areas where MySQL shines and Postgres falls short.

Features I Wish Postgres Had but MySQL Already Has

Areas where PostgreSQL shines and MySQL falls short.

Features I Wish MySQL Had but Postgres Already Has

This guide focuses on HIPAA compliance at the database layer, providing healthcare organizations and database teams with practical guidance for implementing HIPAA Security Rule requirements.

HIPAA Data Security and Retention Requirements

Compare the online index creation difference between Postgres and MySQL

Postgres vs. MySQL: Online Index Creation

SOC 2 Data Security and Retention Requirements for Database Systems and How Bytebase Helps

SOC 2 Data Security and Retention Requirements

Compare the different indexing options between Postgres and MySQL

Postgres vs. MySQL: Indexing Options

Compare the JSON support difference between Postgres and MySQL

Postgres vs. MySQL: JSON Support

While PostgreSQL RLS is a powerful feature, it has inherent design limitations that hinder broader adoption. In this post, we’ll examine these limitations and explore alternatives.

Postgres Row-Level Security (RLS) Limitations and Alternatives

Evaluate several database schema diagram tools, and help you to choose the right one for 2025

Top 4 Free, Open Source Database Schema Diagram Tools to Visualize Database Easier in 2025

An overview of the most popular text-to-SQL AI tools in 2026, including DataGrip, TablePlus, SQL Chat, Vanna.ai, SQLAI.ai, Postgres.new, and DBHub MCP server. Compare features and capabilities to find the best SQL AI assistant for your workflow.

Top 5 Text-to-SQL Query Tools in 2026

Compare the DDL transaction difference between Postgres and MySQL

Postgres vs. MySQL: DDL Transaction Difference

Evaluate several TypeScript ORMs, and help you to choose the right one for 2025

Top TypeScript ORM 2025

Evaluate Prisma and TypeORM, and help you to choose the right TypeScript ORM for 2025

Prisma vs TypeORM: The Better TypeScript ORM in 2025

PostgreSQL 18 features and what they change for running production databases.

What's New in PostgreSQL 18: A DBA's Perspective

Explore alternatives to Amazon RDS, including 

RDS Alternatives in 2025

An extensive comparison between DynamoDB and Cassandra on performance, usability, operability, ecosystem and more.

DynamoDB vs. Cassandra: a Complete Comparison in 2025

An extensive comparison between DynamoDB and MongoDB on performance, usability, operability, ecosystem and more.

RDS vs. DynamoDB: a Complete Comparison in 2025

How gh-ost and pt-online-schema-change compare on architecture, cut-over, foreign keys, and runtime control — for teams choosing a MySQL online schema migration tool.

gh-ost vs pt-online-schema-change

GitHub and Bitbucket are both tools for code collaboration. This article compares the features and pricing of GitHub and Bitbucket.

GitHub vs Bitbucket:a Complete Comparison in 2025

Drizzle ORM vs Prisma comparison: type safety, performance, bundle size, serverless support, migrations, and ecosystem. Find out which TypeScript ORM is right for your project in 2026.

Drizzle ORM vs Prisma: Which TypeScript ORM Should You Use in 2026?

An engineering perspective to evaluate Google AlloyDB and Cloud SQL, and help you to choose the right Google Cloud database for 2025

AlloyDB vs. Cloud SQL: engineering guide to choose the right Google Cloud database for 2025

Understanding DynamoDB Pricing (2025)

A simple comparison of AWS Aurora versus RDS pricing in 2025, helping you understand key differences and choose the right database service for your needs and budget.

AWS Aurora vs. RDS Pricing: A Detailed Comparison 2025

Infrastructure as Code security tools help organizations identify vulnerabilities and misconfigurations in their infrastructure definitions. This post explores the top open-source IaC security tools available in 2025.

Top Open Source Infrastructure as Code (IaC) Security Tools in 2025

Compare the price of the mainstream managed PostgreSQL hosting providers

PostgreSQL Hosting Options in 2025: Pricing Comparison

Complete guide to AWS Aurora pricing: instance types and costs, Aurora Serverless v2 pricing, I/O-Optimized vs Standard, reserved instance savings, and real-world cost examples. Learn how to optimize your Aurora costs.

AWS Aurora Pricing Explained: Instance Types, Serverless, and Cost Optimization (2026)

Database governance tools help organizations manage database changes, enforce policies, and maintain data quality. This post explores the top open-source database governance tools available in 2025.

Top Open Source Database Governance Tools in 2025

Workflow orchestration tools help coordinate tasks, handle errors, and monitor execution processes. In this post, we are taking a look at open source workflow orchestration options

Top Open Source Workflow Orchestration Tools in 2025

Understanding AWS RDS Pricing (2025)

Compare the price of the mainstream managed MySQL hosting providers

MySQL Hosting Options in 2025: Pricing Comparison


## From Supabase to AWS

[Supabase](https://supabase.com/) has become the go-to choice for developers who want to build fast.
It gives you everything in one place — PostgreSQL, Auth, Storage, and Edge Functions — without needing to manage infrastructure.

But as your product matures, new requirements appear that go beyond what Supabase’s all-in-one model can offer:

- **Advanced database management** – high availability, read replicas, automated backups, and fine-tuned performance.
- **Analytics and data warehousing** – integrating with data lakes and large-scale ETL pipelines.
- **Enterprise-grade compliance and security** – meeting SOC, ISO, HIPAA, or FedRAMP standards.
- **Granular IAM and networking** – unifying database access, APIs, and infrastructure under a single identity and policy system.

That's where hyperscalers like [AWS](https://aws.amazon.com/), [GCP](https://cloud.google.com/), and [Azure](https://azure.microsoft.com/) come in. They offer a **best-of-breed ecosystem** — each component is purpose-built, scales independently.

**This guide focuses on AWS**, but the migration principles and architecture patterns apply equally to other cloud providers.

We'll walk you through how to migrate each Supabase component to its AWS counterpart.

---

## Debundle Supabase

| Supabase Component   | Equivalent                                     | Notes                                                   |
| -------------------- | ---------------------------------------------- | ------------------------------------------------------- |
| **Networking & IAM** | VPC + IAM roles/policies                       | AWS foundation - must be set up first                   |
| **Auth**             | Amazon Cognito / BetterAuth / Auth0            | Centralized user management, SSO, and MFA               |
| **Storage**          | Amazon S3                                      | Object storage with IAM-based access and CloudFront CDN |
| **Functions**        | AWS Lambda + API Gateway                       | Event-driven compute for backend logic                  |
| **Realtime**         | AppSync / EventBridge / API Gateway WebSockets | Live updates, subscriptions, or event streams           |
| **Database**         | Amazon RDS / Aurora                            | Migrate last - becomes simple PostgreSQL migration      |

**Recommended migration order:**

This guide uses a **Services-First** approach — decouple Supabase-specific services first, then migrate the database last as a simple PostgreSQL migration.

1. **Networking & IAM** – set up AWS infrastructure (VPC, subnets, IAM roles).
1. **Auth** – migrate to Cognito (decouples from Supabase `auth` schema).
1. **Storage** – migrate to S3 (decouples from Supabase `storage` schema).
1. **Functions** – redeploy to Lambda (update to use Cognito + S3).
1. **Realtime** – replace with AppSync/EventBridge (removes logical replication dependency).
1. **Database** – simple PostgreSQL migration of application data only (`public` schema).

**Why this order?** By migrating services first, the Supabase `auth` and `storage` schemas become dormant. The final database migration is just your application data — lower risk, simpler cutover, and easier to validate.

Always start in **staging**, validate each part, then proceed to production.

### 1. Networking and IAM

> **Note:** The networking and identity concepts in this section apply to all major cloud providers (AWS, GCP, Azure). This guide focuses on AWS implementations, but the architecture patterns translate directly to VPC/IAM (GCP) or VNet/RBAC (Azure).

**Supabase:**
Abstracted networking and simple project-level access roles.

**AWS approach:**
Full-control networking and IAM system for isolation and compliance.

| Concept                | Supabase          | AWS Equivalent                 |
| ---------------------- | ----------------- | ------------------------------ |
| Top-level entity       | Organization      | AWS Organization               |
| Project                | Supabase Project  | AWS Account                    |
| Environment separation | Multiple projects | Separate accounts or VPCs      |
| Access control         | Role-based in app | IAM users, roles, and policies |

**Migration focus:**

1. Create VPC with public and private subnets across multiple Availability Zones.
1. Set up **Security Groups** for database, Lambda, and API Gateway.
1. Configure **Route Tables** and **NAT Gateways** for private subnet internet access.
1. Create **IAM roles** for Lambda, RDS, S3, and Cognito.
1. Set up **VPC endpoints** for AWS service access (S3, DynamoDB, etc.).
1. Use **AWS Organizations** for environment isolation (dev, staging, prod).

**Key advantages:**

- Granular control over infrastructure and networking.
- Centralized access and audit through IAM.
- Broad compliance coverage — [AWS Compliance](https://aws.amazon.com/compliance) vs [Supabase Security](https://supabase.com/security).

### 2. Auth → Amazon Cognito (or Alternatives)

**Supabase:**
[GoTrue](https://supabase.com/docs/guides/auth/auth-go-true)-based Auth with email/password and [OAuth integration](https://supabase.com/docs/guides/auth/social-login), connected to Postgres RLS.

**AWS replacement:**

- [Amazon Cognito](https://aws.amazon.com/cognito/) for user pools, federated identity, and SSO integration.
- Alternatives like [BetterAuth](https://betterauth.com/), [Auth0](https://auth0.com/), or [Clerk](https://clerk.com/) if developer-experience is a priority.

**Migration focus:**

1. Export user data (emails, metadata, OAuth IDs) from `auth.users`.
1. Import into Cognito User Pool.
1. Configure OAuth providers (Google, GitHub, etc.).
1. Update frontend SDKs and backend JWT verification.
1. Update application authorization logic (see RLS section below).
1. Require one-time user re-authentication after migration.

> **Important:** If you're using Supabase Row-Level Security (RLS) policies, they reference `auth.uid()` and won't work after migrating to Cognito. See the **Handling RLS Policies** section in the Database migration step for strategies to address this.

**Key advantages:**

- Deep IAM integration with AWS services.
- SAML/OIDC support and MFA.
- Fine-grained access control and security compliance.

### 3. Storage → Amazon S3

**Supabase:**
S3-compatible object storage managed inside Supabase, with integrated access policies and signed URLs.

**AWS replacement:**

- [Amazon S3](https://aws.amazon.com/s3/) for raw file storage.
- [CloudFront](https://aws.amazon.com/cloudfront/) for CDN delivery.

**Migration focus:**

1. Create an S3 bucket with IAM-based access.
1. Copy data using `aws s3 sync` or `rclone`.
1. Recreate folder structure and permissions.
1. Update signed URL logic to use S3 pre-signed URLs.
1. Add CloudFront for caching if needed.

**Key advantages:**

- Lifecycle policies, versioning, and encryption (SSE-KMS).
- Regional redundancy and cost-based storage tiers.
- Tight integration with Lambda, Athena, and Redshift.

### 4. Functions → AWS Lambda

**Supabase:**
[Edge Functions](https://supabase.com/docs/guides/functions/edge-functions) built with [Deno](https://deno.com/) for lightweight APIs.

**AWS replacement:**

- [AWS Lambda](https://aws.amazon.com/lambda/) for event-driven functions.
- [API Gateway](https://aws.amazon.com/api-gateway/) for HTTP endpoints.

**Migration focus:**

- Rewrite Deno functions in Node.js, Python, or Go.
- Deploy via Lambda console, CLI, or IaC (Terraform/CDK).
- Store environment variables in **Secrets Manager** or **Parameter Store**.
- Connect Lambda to S3, DynamoDB, or EventBridge as needed.

**Key advantages:**

- Multiple runtimes and deployment methods.
- Native observability via CloudWatch.
- Scales automatically with demand.

### 5. Realtime and Events → AppSync / EventBridge

**Supabase:**
Realtime engine based on Postgres logical replication and WebSockets.

**AWS replacements:**

- [AppSync](https://aws.amazon.com/appsync/) – GraphQL subscriptions for live updates.
- [EventBridge](https://aws.amazon.com/eventbridge/), [SNS](https://aws.amazon.com/sns/), or [SQS](https://aws.amazon.com/sqs/) – event-driven messaging.
- [API Gateway WebSockets](https://aws.amazon.com/api-gateway/) – persistent connections for custom protocols.

**Migration focus:**

1. Identify realtime use cases (chat, collaboration, notifications).
1. Choose appropriate AWS service per pattern.
1. Replace database-triggered realtime with event-driven design.

**Key advantages:**

- Decoupled architecture.
- Scalable pub/sub and async event flows.
- Integrates natively with Lambda and analytics pipelines.

### 6. Database → Amazon RDS / Aurora

**Supabase:**
Managed PostgreSQL with `auth`, `storage`, and `public` schemas.

**AWS replacement:**

- **Amazon RDS (PostgreSQL)** – Multi-AZ, automated backups, PITR, read replicas.
- **Amazon Aurora (PostgreSQL-compatible)** – high-performance clustered Postgres.
- **DynamoDB** – optional for NoSQL or key-value workloads.

**Why migrate last:**

By this point, Auth is on Cognito, Storage is on S3, and Realtime has been replaced with AppSync/EventBridge. The Supabase `auth` and `storage` schemas are now dormant — your application no longer uses them.

This makes the database migration simple — just a vanilla PostgreSQL migration of your application data (the `public` schema).

#### Handling Row-Level Security (RLS) Policies

Supabase uses PostgreSQL [Row-Level Security (RLS)](https://supabase.com/docs/guides/auth/row-level-security) policies heavily. These policies reference Supabase-specific functions and the `auth.users` table:

```sql
-- Example Supabase RLS policy
CREATE POLICY "Users can only see their own data"
ON public.profiles
FOR SELECT
USING (auth.uid() = user_id);
```

The problem: `auth.uid()` and `auth.jwt()` are Supabase-specific functions that won't work after migrating to Cognito.

**Migration Strategy: Replace RLS with Application-Level Authorization**

The recommended approach is to move authorization logic from the database to your application layer (Lambda functions):

- **More flexible** – Works with any auth provider (Cognito, Auth0, BetterAuth, etc.).
- **Easier to test** – Authorization logic can be unit tested independently.
- **Framework-agnostic** – Not tied to PostgreSQL-specific features.
- **Modern best practice** – Industry standard for cloud-native applications.
- **Better debugging** – Authorization failures are easier to trace in application code.

Implementation example:

```javascript
// Lambda function with application-level authorization
const getUserProfile = async (event) => {
  // Extract Cognito user ID from JWT claims
  const cognitoUserId = event.requestContext.authorizer.claims.sub;

  // Enforce authorization in application code
  const profile = await db.query('SELECT * FROM profiles WHERE user_id = $1', [cognitoUserId]);

  return profile;
};
```

**Database migration focus:**

1. **Audit RLS policies** – Identify all RLS policies in your schema (see RLS migration strategy above).
1. Set up RDS/Aurora instance in the VPC created in step 1.
1. Export `public` schema and data using `pg_dump` (ignore dormant `auth` and `storage` schemas).
1. Restore into RDS or Aurora (same Postgres version).
1. **Implement application-level authorization** – Migrate RLS logic to Lambda functions as shown above.
1. **Remove RLS policies** – Drop policies once application-level authorization is tested and deployed.
1. Recreate extensions (e.g., `pgcrypto`, `uuid-ossp`) if used in application.
1. Validate schema and queries in staging environment.
1. Update application connection strings to point to RDS/Aurora.
1. Perform final cutover during low-traffic window.

**Key advantages:**

- Performance tuning and [CloudWatch metrics](https://aws.amazon.com/cloudwatch/).
- Private networking in VPC with security groups.
- Access to AWS analytics tools ([Redshift](https://aws.amazon.com/redshift/), [Athena](https://aws.amazon.com/athena/), [Glue](https://aws.amazon.com/glue/)).

## Conclusion

Migrating from Supabase to AWS isn't just a lift-and-shift — it's a step toward scalable, enterprise-ready infrastructure.

Use the **Services-First** approach to decouple components gradually:
**Networking & IAM → Auth → Storage → Functions → Realtime → Database.**

By migrating services first, the final database migration becomes a simple PostgreSQL-to-PostgreSQL operation with just your application data — lower risk, simpler cutover, and easier to validate.

Supabase helps you **build fast**.
AWS helps you **scale next** — with advanced database management, analytics, IAM, and compliance.

When done right, the migration lays a foundation your product can grow on for years to come.



Backing up PostgreSQL is essential for reliability and disaster recovery. The open-source ecosystem offers several strong tools - each with unique design goals, languages, and ideal use cases.

Below is a curated list of the top PostgreSQL backup solutions, compared across multiple dimensions: language and ideal use cases.

[![star-history](/content/blog/top-open-source-postgres-backup-solution/star-history.webp)](https://www.star-history.com/#databasus/databasus&wal-g/wal-g&pgbackrest/pgbackrest&EnterpriseDB/barman&pgmoneta/pgmoneta&eduardolat/pgbackweb)

## Databasus

- **GitHub:** https://github.com/databasus/databasus
- **Language:** Go + TypeScript
- **Maintainer:** Community
- **License:** Apache 2.0
- **Interface:** Web UI
- **Supported Databases:** PostgreSQL, MySQL, MariaDB, MongoDB
- **Best For:** Teams needing a self-hosted, web-based backup management solution

Databasus (rebranded from Postgresus) is a self-hosted database backup management tool with a modern web UI. It offers flexible scheduling (hourly, daily, weekly, monthly, or cron), multiple storage destinations (S3, Google Drive, NAS, SFTP), AES-256-GCM encryption, and team features like role-based access control and audit logging. Notifications are supported via email, Telegram, Slack, Discord, and webhooks.

![databasus](/content/blog/top-open-source-postgres-backup-solution/databasus.webp)

## WAL-G

- **GitHub:** https://github.com/wal-g/wal-g
- **Language:** Go
- **Maintainer:** Community
- **License:** Apache License 2.0
- **Interface:** CLI
- **Supported Databases:** PostgreSQL, MySQL/MariaDB, MS SQL Server, MongoDB (beta), Redis (beta)
- **Best For:** Cloud-native and multi-database environments

WAL-G is an archival and restoration tool for databases in the Cloud, the spiritual successor to [WAL-E](https://github.com/wal-g/wal-e). It's built for performance, with parallel compression, encryption, and seamless cloud storage integration. Its multi-database support makes it ideal for teams managing mixed database stacks.

## pgBackRest

<HintBlock type="warning">

**No longer maintained as of April 2026.** The pgBackRest repository was [archived on April 27, 2026](https://github.com/pgbackrest/pgbackrest#notice-of-obsolescence) and is now read-only. The maintainer cited the loss of corporate sponsorship after Crunchy Data was sold and the inability to find a sustainable funding model. **v2.58.0 is the final release** — no further bug fixes, security patches, or features. Existing deployments continue to work, but new setups in 2026+ should evaluate the alternatives below. A community fork may emerge under a new name.

</HintBlock>

- **GitHub:** https://github.com/pgbackrest/pgbackrest (archived)
- **Language:** C
- **Maintainer:** Formerly Crunchy Data — unmaintained as of April 2026
- **License:** MIT License
- **Interface:** CLI
- **Supported Databases:** PostgreSQL only
- **Best For:** Existing deployments only — not recommended for new setups

pgBackRest was designed for speed, reliability, and flexibility, supporting full, differential, and incremental backups with parallel processing, compression, encryption, and cloud storage integration. It was widely deployed in production through the early 2020s and remains functional at v2.58.0, but no longer accepts contributions. New deployments should consider WAL-G, Barman, or pgmoneta.

## Barman

- **GitHub:** https://github.com/EnterpriseDB/barman
- **Language:** Python
- **Maintainer:** EnterpriseDB (EDB)
- **License:** GNU GPL 3
- **Interface:** CLI
- **Supported Databases:** PostgreSQL only
- **Best For:** Enterprises requiring centralized backup management

Barman (**B**ackup **A**nd **R**ecovery Manager) is an open-source administration tool for disaster recovery of PostgreSQL servers written in Python. It allows your organisation to perform remote backups of multiple servers in business critical environments to reduce risk and help DBAs during the recovery phase.

## pgmoneta

- **GitHub:** https://github.com/pgmoneta/pgmoneta
- **Language:** C
- **Maintainer:** Community
- **License:** BSD-3-Clause
- **Interface:** CLI (daemon mode)
- **Supported Databases:** PostgreSQL only
- **Best For:** Teams needing efficient daemon-based backup with incremental support

pgmoneta is a backup and restore solution for PostgreSQL, named after the Roman Goddess of Memory. It runs as a daemon and supports full and incremental backups (PostgreSQL 14+), multiple compression options (gzip, zstd, lz4, bzip2), AES encryption, and WAL shipping. It features Prometheus monitoring integration, remote management capabilities, and TLS v1.2+ support. Built with a process-based model using shared memory and libev for efficient network operations.

## pgBackWeb

<HintBlock type="warning">

pgBackWeb wraps pgBackRest, which was [archived in April 2026](#pgbackrest). pgBackWeb itself remains active, but its underlying engine no longer receives updates. Long-term users may want to track whether pgBackWeb migrates to a different backend.

</HintBlock>

- **GitHub:** https://github.com/eduardolat/pgbackweb
- **Language:** Go + JavaScript
- **Maintainer:** Community
- **License:** AGPL-3.0
- **Interface:** Web UI
- **Supported Databases:** PostgreSQL (via pgBackRest — see notice above)
- **Best For:** Teams preferring visual management on existing pgBackRest deployments

pgBackWeb provides a user-friendly web dashboard on top of pgBackRest. It enables visual monitoring, restore operations, and scheduling — ideal for smaller teams or users who prefer GUI-based workflows instead of the command line.

![pgbackweb](/content/blog/top-open-source-postgres-backup-solution/pgbackweb.webp)

## Comparison Table

| Tool           | Language        | License      | Interface    | Multi-DB Support | Cloud Storage       |
| -------------- | --------------- | ------------ | ------------ | ---------------- | ------------------- |
| **Databasus**  | Go + TypeScript | Apache 2.0   | Web UI       | ✅               | ✅                  |
| **WAL-G**      | Go              | Apache 2.0   | CLI          | ✅               | ✅                  |
| **pgBackRest** ⚠️ | C               | MIT          | CLI          | ❌               | ✅                  |
| **Barman**     | Python          | GNU GPL 3    | CLI          | ❌               | ✅                  |
| **pgmoneta**   | C               | BSD-3-Clause | CLI (daemon) | ❌               | ❌                  |
| **pgBackWeb**  | Go + JavaScript | AGPL-3.0     | Web UI       | ❌               | ✅ (via pgBackRest ⚠️) |

⚠️ **pgBackRest is no longer maintained as of April 2026** — see the [pgBackRest section](#pgbackrest) for details.

## Choosing the Right Tool

- **Databasus** — great for teams wanting a self-hosted web UI with multi-database support.
- **WAL-G** — best for multi-database, cloud-native setups. **Recommended for new PostgreSQL deployments.**
- **pgBackRest** — feature-rich and battle-tested, but **no longer maintained as of April 2026**. Suitable only for existing installations; do not use for new deployments.
- **Barman** — fits enterprise environments with strict compliance. **Recommended for new PostgreSQL deployments needing centralized management.**
- **pgmoneta** — lightweight daemon-based solution with incremental backup and monitoring support.
- **pgBackWeb** — useful if you already run pgBackRest and want a GUI; reconsider for new setups given the underlying engine's archival.

Each project offers a unique trade-off between simplicity, scalability, and ecosystem support. Pick based on your environment’s scale, cloud strategy, and team expertise.



## What is Enterprise Database Management?

Enterprise Database Management (EDM) is the practice of organizing, securing, and optimizing database systems across large organizations. It encompasses the tools, processes, and strategies needed to manage multiple database platforms while ensuring data integrity, security, regulatory compliance, and business continuity. Unlike basic database administration, EDM coordinates cross-functional teams—developers, DBAs, security, and platform engineers—to handle complex database ecosystems at scale:

- **Multiple databases**: PostgreSQL, MySQL, Oracle, SQL Server, MongoDB—all at once
- **Cross-functional teams**: Developers, DBAs, security, platform teams—all need access
- **Regulatory compliance**: GDPR, HIPAA, PCI-DSS, SOC2—all enforced
- **Scale**: Petabytes of data, global distribution
- **Business continuity**: Zero downtime, instant recovery

## Brief History of Enterprise Database Management

### Standalone Databases (1970s-1990s)

Early databases were command-line only. IBM created IMS (1966) for NASA, then System R (1974-1977) introduced SQL. Oracle commercialized SQL in 1979. DBAs typed commands, everyone else waited. This couldn't scale.

### Rise of Database Management Tools (1990s-2010s)

Databases alone weren't enough. Oracle launched [Oracle Enterprise Manager (OEM)](https://www.oracle.com/enterprise-manager/) in 1996, Microsoft followed with [SQL Server Management Studio (SSMS)](https://learn.microsoft.com/en-us/ssms/). Both dominant vendors creating management tools wasn't coincidence—enterprises demanded better control. These tools replaced command lines with visual interfaces for monitoring, backups, and optimization.

### Cloud Era (2010s-2022)

Cloud providers changed the game. AWS RDS, Azure SQL Database, Google Cloud SQL—they offered simplified versions of what OEM and SSMS provided. One-click backups, automatic failovers, built-in monitoring. No more infrastructure management. DBAs could focus on data, not servers. But these cloud consoles still operated in silos, managing databases in isolation from development pipelines.

### The AI Shift (2023-Present)

Large language models transformed expectations. Natural language to SQL, AI-assisted schema reviews, automated migration generation—development workflows finally got intelligent assistance. On the operations side: predictive scaling, anomaly detection, self-healing databases. AI also tackled governance—sensitive data discovery, automated compliance checks, intelligent access recommendations.

The breakthrough: AI bridges the gap between operations and development. Database changes that took days now happen in hours, with AI handling the translation between what developers want and what databases need.

## The Gap Between Operations and Development Workflows

These tools handled operations well but ignored development needs. No version control integration. No CI/CD pipelines. Security teams managed access separately. Platform teams couldn't automate provisioning.

Cloud made this problem more obvious. Applications deployed in minutes, databases still took days. Developers had CI/CD for code, but database changes remained manual tickets. Cloud promised agility—databases became the bottleneck.

The core problem: **these tools focused on operational tasks, not collaborative workflows**. Modern enterprises need all teams working together—traditional tools never delivered that.

The AI shift adds new complexity: validating AI-generated changes, protecting sensitive data from model exposure, and deciding when to trust automation versus human judgment.

In our next article, we'll explore the evolution of enterprise database management in detail—tracing its journey from mainframe-era centralized systems through client-server architectures to cloud-native platforms and the AI shift, and examining how these changes are reshaping database management for modern development teams.



PostgreSQL’s transaction system is built around a simple but powerful idea: every transaction gets a **Transaction ID (XID)** - a 32-bit integer that powers its **MVCC (Multi-Version Concurrency Control)** engine.

MVCC lets multiple users read and write data at the same time without blocking each other.
But those transaction IDs are finite, and eventually they **wrap around**.

If not handled properly, wraparound can make data invisible or even force the entire database into emergency shutdown.
Let’s understand why.

### How Postgres Differs from Other Databases

PostgreSQL uses a **tuple-based** MVCC model - every data change creates a new version (tuple) of a row stored directly in the table.

Each tuple has two hidden fields: `xmin` and `xmax`. `xmin` is the transaction ID that created the tuple, and `xmax` is the transaction ID that deleted or replaced it.

Other databases handle versioning differently:

| Database           | MVCC type           | Where old versions are stored      | Wraparound risk |
| ------------------ | ------------------- | ---------------------------------- | --------------- |
| **PostgreSQL**     | Tuple-based         | In the main table (needs `VACUUM`) | ✅ Yes           |
| **MySQL (InnoDB)** | Undo-log-based      | Undo logs in system tablespace     | ❌ No            |
| **SQL Server**     | Version-store-based | Tempdb version store               | ❌ No            |
| **Oracle**         | Undo-log-based      | Undo segments                      | ❌ No            |

In short:
PostgreSQL keeps old rows **inline** with the table, and each one carries its own transaction ID.
That design enables powerful visibility control but also means transaction IDs must eventually be **reused** - leading to the wraparound problem.
Other databases store old versions separately, so their transaction identifiers can grow freely without ever wrapping around.

### What Is Transaction Wraparound

PostgreSQL’s transaction IDs are **32-bit integers** (`0` to `4,294,967,295`).
After the counter hits its limit, it **wraps around** back to 3 again.

You can picture XIDs as points on a **circle**, not a straight line.

![Transaction ID (XID) Wraparound](/content/blog/postgres-transaction-id-wraparound/pg-xid-cycle-circle.webp)

When the counter wraps, very old tuples may suddenly appear to have "future" XIDs and become **invisible** to all new transactions.

![Transaction ID (XID) Wraparound](/content/blog/postgres-transaction-id-wraparound/pg-xid-cycle.webp)

To prevent this, Postgres periodically **freezes** old tuples - marking them with a special `FrozenXID`, meaning "committed long ago, always visible."

![Transaction ID (XID) Wraparound](/content/blog/postgres-transaction-id-wraparound/pg-xid-freeze.webp)

### Consequences of Wraparound

If the database fails to freeze tuples in time, it risks data corruption.
When `datfrozenxid` becomes dangerously old, Postgres refuses new writes and may shut down with errors like:

```
PANIC: database is not accepting commands to avoid wraparound data loss
```

#### Real-world cases

- **Sentry (2024):**
  Sentry’s Postgres database stopped accepting writes after autovacuum couldn’t keep up with freezing old transaction IDs. The system hit the wraparound limit, forcing emergency manual vacuuming and downtime.
  [https://blog.sentry.io/transaction-id-wraparound-in-postgres/](https://blog.sentry.io/transaction-id-wraparound-in-postgres/)

- **Mailchimp/Mandrill (2016):**
  A busy shard’s autovacuum fell behind, triggering wraparound protection and halting writes. Recovery required truncations and manual vacuums, leading to roughly 40 hours of outage.
  [https://mailchimp.com/what-we-learned-from-the-recent-mandrill-outage/](https://mailchimp.com/what-we-learned-from-the-recent-mandrill-outage/)

These cases show that wraparound isn’t theoretical - it’s one of the few PostgreSQL maintenance failures that can completely stop production systems.

### How to Monitor and Prevent Wraparound

#### 1. Autovacuum is the First Line of Defense

Autovacuum automatically scans tables and freezes tuples before they age out.
Key parameters:

- `autovacuum_freeze_max_age` – threshold for wraparound prevention
- `vacuum_freeze_table_age` – when to start freezing during normal vacuum
- `vacuum_freeze_min_age` – minimum XID age before freezing allowed

If autovacuum is off or slow, wraparound danger grows silently.

#### 2. Check XID Age with SQL

To see how close your database is to wraparound:

```sql
SELECT datname, age(datfrozenxid) AS xid_age
FROM pg_database
ORDER BY xid_age DESC;
```

For table-level detail:

```sql
SELECT relname, age(relfrozenxid) AS xid_age
FROM pg_class
WHERE relkind = 'r'
ORDER BY xid_age DESC;
```

⚠️ **Guidelines**

- Above **1.5 billion** → warning zone
- Above **2 billion** → database may lock writes

#### 3. Cloud Provider Recommendations

**AWS RDS / Aurora**
Use `postgres_get_av_diag` to monitor autovacuum health and aging tables —
[https://aws.amazon.com/blogs/database/prevent-transaction-id-wraparound-by-using-postgres_get_av_diag-for-monitoring-autovacuum/](https://aws.amazon.com/blogs/database/prevent-transaction-id-wraparound-by-using-postgres_get_av_diag-for-monitoring-autovacuum/)

**Google Cloud SQL**
Cloud SQL provides a Recommender for High Transaction ID Utilization -
[https://cloud.google.com/sql/docs/postgres/recommender-high-transactionid-utilization](https://cloud.google.com/sql/docs/postgres/recommender-high-transactionid-utilization)

General advice:

- Never disable autovacuum.
- Schedule manual `VACUUM FREEZE` during off-peak hours.
- Avoid long-running idle transactions that block freezing.

### The Challenge of Moving to 64-bit Transaction IDs

At first glance, the easiest fix would be to make transaction IDs **64-bit** instead of 32-bit.
That would raise the ceiling from 4 billion transactions to roughly **18 quintillion** - effectively eliminating wraparound forever.

This idea has been discussed for years, with real prototypes already attempted:

- **Early discussions (2018–2019):**
  [https://www.postgresql.org/message-id/flat/DA1E65A4-7C5A-461D-B211-2AD5F9A6F2FD%40gmail.com](https://www.postgresql.org/message-id/flat/DA1E65A4-7C5A-461D-B211-2AD5F9A6F2FD%40gmail.com)
  Developers debated whether to store full 64-bit IDs or use a **hybrid scheme** (16-bit epoch + 48-bit XID) to retain compatibility.

- **Experimental patch for Postgres 15 (2021):**
  [https://www.postgresql.org/message-id/flat/CACG=ezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe=pyyjVWA@mail.gmail.com](https://www.postgresql.org/message-id/flat/CACG=ezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe=pyyjVWA@mail.gmail.com)
  It proved feasible but caused major ripple effects:

  - Every tuple grows by 8 bytes (`xmin` + `xmax`).
  - Index and WAL formats must be redesigned.
  - Replication and visibility logic rely on 32-bit arithmetic.

- **Community view:**
  [https://news.ycombinator.com/item?id=19083745](https://news.ycombinator.com/item?id=19083745)
  Developers agreed the change would *solve wraparound permanently* but **break on-disk compatibility**, forcing every database to migrate storage format.

For now, the community focuses on improving **autovacuum efficiency** and **wraparound monitoring**, accepting that 32-bit XIDs remain part of the architecture - at least until a cleaner migration path emerges.

### Best Practices

- ✅ Keep autovacuum **enabled and tuned**
- ✅ Monitor XID age regularly
- ✅ Vacuum frequently on high-write tables
- ✅ Avoid long-running transactions
- ✅ Run `VACUUM FREEZE` during maintenance windows
- ✅ Partition or archive old data to reduce bloat


The CI/CD pipeline approach moves database change onto the same pipeline as application code. Migration scripts live in Git. CI runs lint and review. Deployment runs through stages.

This post walks the approach end-to-end — what the pipeline gates, the work it leaves outside, and the tools that fit.

<HintBlock type="info">

The pipeline-led approach sits at Level 3 of [the 6 levels of database automation](/blog/database-automation-levels).

</HintBlock>

## What the pipeline does

Every change runs through the same path. Validate. Promote. Approve. Record.

### Validate

SQL review runs on the pull request. Syntax errors, missing indexes, unsafe operations, naming-rule violations — all caught before merge. The ruleset applies across environments; strictness varies. Production runs the full set. Dev runs a subset.

### Promote

The migration applies in dev. Then staging. Then production. Each stage runs the same script against progressively more realistic data. Failures stop the chain.

### Approve

Approval gates sit between stages. Routine changes auto-promote into dev and staging. Production-bound DDL waits for a human. The approver sees the SQL, the validation results, and the rollout plan in one record.

### Record

Every applied migration is logged with version, environment, executor, and timestamp. Schemas across environments are compared automatically. Drift — a change made outside the pipeline — triggers an alert.

## A change through the pipeline

A developer adds a nullable column to a 12M-row `users` table.

**Pull request.** Migration committed:

```sql
-- V042__add_user_email_verified_column.sql
ALTER TABLE users ADD COLUMN email_verified BOOLEAN DEFAULT NULL;

CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_users_email_verified
ON users(email_verified) WHERE email_verified = FALSE;
```

SQL review flags two things. Index creation will take ~10 minutes at production scale. The partial-index `WHERE` clause keeps the index small but skews cardinality.

**Dev.** Migration applies in 2 seconds against a 10K-row database. Integration tests pass.

**Staging.** Production-like volume. Migration takes 8 minutes. Replication lag spikes to 45 seconds during the index build. QA verifies the application handles the new nullable column.

**Production.** DBA approves after staging completes clean. Deployment runs during a low-traffic window. Migration takes 11 minutes. Application deploys after database confirmation.

The pipeline records every step. Each environment has its own audit trail. The migration script is the same across all four.

Index strategy varies by engine. PostgreSQL uses `CREATE INDEX CONCURRENTLY`. MySQL uses `ALGORITHM=INPLACE`, falling back to `gh-ost` or `pt-online-schema-change` for tables the engine would otherwise copy. The developer picks the strategy. The pipeline enforces that the choice flows through review.

## Where it stops short

The pipeline gates one class of work: planned, version-controlled schema changes. Several others fall outside.

- **Ad-hoc operations.** Emergency hotfixes, one-off data patches, an `ANALYZE` during an incident — none start as a pull request. [How to Handle Ad-hoc Database Data Changes](/blog/how-to-handle-adhoc-database-data-change) covers the workflow for these.
- **Credential management.** Database credentials live in PAM, or in developer laptops. The pipeline runs as a service identity, not as the developer.
- **Read-path activity.** Queries, exports, ad-hoc lookups don't show up in the migration log.
- **Policy beyond the merge.** Naming rules and lock-grade checks run at PR review. Once merged, nothing rechecks at execution.

The pipeline gates planned change. It does not gate everything that touches the database.

[Securing Database Change](/blog/top-database-change-management-tools) covers the same gap from the security stack — bastion, ITSM, PAM.

## Tools that fit

Three open-source tools cover the pipeline's core mechanics.

- **Liquibase, Flyway** — CLI-first migration runners. Apply migrations from a changelog, track which have run, integrate with any CI system. Java-based.
- **Bytebase** — web GUI plus GitOps. SQL review, approvals, and stage promotion built in. Single Go binary.

| Capability                      | Liquibase | Flyway     | Bytebase         |
| ------------------------------- | --------- | ---------- | ---------------- |
| Apply migrations from changelog | ✓         | ✓          | ✓                |
| SQL review built in             | Pro plan  | Teams plan | Free, 200+ rules |
| Stage promotion + approvals     | Manual    | Manual     | Built in         |
| Schema drift detection          | —         | Enterprise | Built in         |
| Web UI                          | —         | —          | ✓                |

CLI-first teams use Liquibase or Flyway and orchestrate the pipeline themselves. Teams that want the pipeline pre-built use Bytebase.

## Where this lands

A CI/CD pipeline is Level 3 in [the 6 levels of database automation](/blog/database-automation-levels). It eliminates the manual hand-off from developer to DBA for planned schema change.

Not every team needs the full pipeline. Read-only analytical databases, ephemeral dev environments, and small teams (under 10 databases, under 5 developers) can run with version control plus a CLI runner. Add the pipeline as the team and database count grow.

The gap is what Level 4 platforms close: ad-hoc operations, credentials, read-path activity, post-merge policy. The pipeline-led approach is the strongest L3 a team can build. It is not L4.


The
Bytebase Blog

Explore the standard for database development

Solutions & Platform

Comparisons

Legal

Resources

Company