How to store, rotate, and scope database credentials: secrets managers, dynamic credentials, the application path vs the human path, and the mistakes that leak passwords.

Managing Database Passwords and Secrets: Best Practices

A guide to audit logging in MySQL — from the general query log to audit plugins, binlog-based CDC, and Bytebase.

MySQL Audit Logging Guide

Every critical asset has its system of record, except the database. Bytebase is the one. The standard for database development.

The Standard for Database Development

Dynamic data masking is chosen by access path, not product. Five approaches (engine-native, in-database, application, BI layer, and Bytebase) and which caller each one masks.

How to Implement Dynamic Data Masking: Five Approaches by Access Path

Static vs dynamic data masking, when each applies, how they differ on backups, performance, and reversibility, and when to run both.

Static vs Dynamic Data Masking: When to Use Which

The static data masking tools that produce safe non-production data, Delphix, Tonic.ai, and greenmask compared, plus how to roll your own when no tool fits.

Static Data Masking Tools (and How to Roll Your Own)

Compare BigQuery data masking options: native column-level dynamic data masking (built-in masking rules via policy tags and data policies, Dataplex catalog) and Bytebase fleet-wide masking.

BigQuery Dynamic Data Masking

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 with PostgreSQL, covering my day-to-day development workflow, the tools I actually use, and real-world examples

How I Ship Features with Postgres

A practical look at what LGPD (Brazil's General Personal Data Protection Act) means for database operations, how it differs from GDPR, and the controls teams need to actually comply.

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 on edition gate, policy management, and 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


PostgreSQL's [built-in Row-Level Security (RLS)](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) allows database administrators to define policies that control which rows can be returned by queries or modified by data manipulation commands on a per-user basis. When enabled, all access to a table must be allowed by a security policy, with table owners typically bypassing these restrictions unless explicitly configured otherwise.

Key characteristics include:

- Enabled at the table level with `ALTER TABLE ... ENABLE ROW LEVEL SECURITY`
- Policies can be specific to commands (SELECT, INSERT, UPDATE, DELETE) or roles
- Uses Boolean expressions to determine which rows are visible/modifiable
- Multiple policies can be combined using OR (permissive) or AND (restrictive)
- Superusers and roles with `BYPASSRLS` attribute bypass row security

While powerful, RLS has performance impact , limited flexibility, and operational overhead that hinder broader adoption. Let's review them in details and discuss the alternatives.

## Performance Impact

Let me break down the detailed performance differences between PostgreSQL RLS and views, examining the internal mechanisms that cause these performance disparities.

RLS policies are evaluated for _every single row_ during query execution. When you query a table with RLS enabled, PostgreSQL:

1. Scans the table (or uses an index)
1. For each row retrieved, evaluates ALL applicable RLS policies
1. Only returns rows that pass the policy checks
1. This happens even if the query has its own WHERE clauses

```sql
-- RLS Policy
CREATE POLICY tenant_isolation ON orders
FOR ALL TO app_user
USING (tenant_id = current_setting('app.tenant_id')::int);

-- This query will:
-- 1. Scan orders table
-- 2. For EACH row, check if tenant_id matches current setting
-- 3. Apply the user's WHERE clause
-- 4. Return matching rows
SELECT * FROM orders WHERE status = 'pending';
```

**Policy Composition Complexity**
Multiple RLS policies on the same table are combined with AND logic, requiring evaluation of each policy for every row:

```sql
-- Multiple policies compound the evaluation cost
CREATE POLICY tenant_policy ON orders
USING (tenant_id = current_setting('app.tenant_id')::int);

CREATE POLICY department_policy ON orders
USING (department_id IN (
  SELECT dept_id FROM user_departments
  WHERE user_id = current_setting('app.user_id')::int
));

-- Now EVERY row must pass BOTH policy checks
```

### Alternatives: Views

**Pre-Filtered Result Sets**
Views with security predicates are resolved during query planning, allowing the optimizer to push predicates down and use indexes effectively:

```sql
-- Security view
CREATE VIEW tenant_orders AS
SELECT * FROM orders
WHERE tenant_id = current_setting('app.tenant_id')::int;

-- Query against view
SELECT * FROM tenant_orders WHERE status = 'pending';

-- PostgreSQL can optimize this as:
-- SELECT * FROM orders
-- WHERE tenant_id = current_setting('app.tenant_id')::int
--   AND status = 'pending'
-- And use compound indexes on (tenant_id, status)
```

**Index Utilization**
The query planner can effectively use indexes when security predicates are part of the base query rather than row-by-row filters:

```sql
-- With RLS: Index on tenant_id might not be used optimally
-- because the security check happens after row retrieval

-- With views: Can use compound index (tenant_id, status) effectively
CREATE INDEX idx_orders_tenant_status ON orders(tenant_id, status);
```

The fundamental issue is that RLS operates as a post-processing security filter rather than an integral part of query optimization, while views allow the security constraints to be optimized as part of the core query execution plan.

The RLS version must:

1. Perform the full join
1. Evaluate RLS policies on each joined row
1. Filter results

The View version can:

1. Use indexes to pre-filter both tables
1. Join only relevant rows
1. Apply final predicates efficiently

Of course, View has its own limitations:

- **Proliferation of Views**: May need many views for different access patterns
- **Maintenance Overhead**: Changes to base tables may require view updates
- **Limited Dynamism**: Less flexible for highly dynamic permission models
- **Write Operations**: More complex to handle INSERT/UPDATE operations

## Flexibility Limitation

**SQL-Only Policy Expressions**

RLS policies are constrained to SQL expressions, which limits what you can express:

```sql
-- RLS can only do this:
CREATE POLICY simple_tenant_policy ON documents
USING (tenant_id = current_setting('app.tenant_id')::int);

-- But cannot do complex business logic like:
-- "Users can access documents if they're in the same department
--  AND it's during business hours
--  AND they've completed required training
--  AND the document hasn't been flagged by content moderation
--  AND external compliance API approves access"
```

**Static Context Limitations**

RLS policies are evaluated with limited context - primarily database session variables and current user information:

```sql
-- Limited to session context
CREATE POLICY time_based_policy ON sensitive_data
USING (
  EXTRACT(hour FROM NOW()) BETWEEN 9 AND 17 -- Crude business hours
  AND EXTRACT(dow FROM NOW()) BETWEEN 1 AND 5 -- Weekdays only
);

-- Cannot consider:
-- - User's actual timezone and location
-- - Company-specific holiday calendar
-- - User's current device/IP reputation
-- - Recent security events or risk scores
-- - Dynamic compliance requirements
```

**No External System Integration**

RLS cannot make external API calls or integrate with other systems:

```sql
-- This is impossible in RLS:
-- CREATE POLICY compliance_policy ON financial_records
-- USING (external_compliance_service_check(user_id, document_id, current_timestamp));

-- You're limited to data that exists in your PostgreSQL instance
```

### Alternatives: Application-Level Logic

While RLS forces you to work within the constraints of SQL and database session context, modern authorization systems can incorporate any data source, apply any business logic, and make decisions based on the full context of each request.

Below shows an ABAC (Attribute-Based Access Control) system that incorporates different attribute types into authorization decisions:

```javascript
// Using Casbin or similar ABAC engine
const authorizationEngine = {
  async checkAccess(subject, resource, action, context) {
    const policy = await this.evaluatePolicy({
      // User attributes
      user: {
        id: subject.id,
        roles: subject.roles,
        department: subject.department,
        clearanceLevel: subject.clearanceLevel,
        lastTrainingDate: subject.lastTrainingDate,
        currentLocation: await geoService.getLocation(context.ip),
        riskScore: await riskEngine.getUserRiskScore(subject.id),
      },

      // Resource attributes
      resource: {
        id: resource.id,
        classification: resource.dataClassification,
        owner: resource.owner,
        createdDate: resource.createdDate,
        lastModified: resource.lastModified,
        complianceFlags: await complianceService.getFlags(resource.id),
      },

      // Environmental attributes
      environment: {
        currentTime: new Date(),
        userAgent: context.userAgent,
        networkLocation: context.networkLocation,
        isBusinessHours: await businessCalendar.isBusinessHours(),
        threatLevel: await securityService.getCurrentThreatLevel(),
      },

      action: action,
    });

    return policy.decision;
  },
};

// Usage
const canAccess = await authorizationEngine.checkAccess(
  currentUser,
  requestedDocument,
  'read',
  requestContext,
);
```

## Operational Overhead

**Management Overhead**

DBAs become organizational bottlenecks when managing RLS policies due to the manual intervention required at every stage of the policy lifecycle. Policy creation demands deep PostgreSQL expertise to craft secure SQL logic while analyzing performance implications and cross-policy dependencies. Managing existing policies becomes increasingly complex as organizations accumulate hundreds of interconnected policies without proper versioning, dependency tracking, or impact analysis capabilities. Decommissioning policies requires manual archaeological work to identify relationships and ensure safe removal without breaking dependent systems.

**Developer Self-Service Usability Limitations**

Developers face friction when working with RLS as there are no self-service capabilities for access management or testing. RLS provides no mechanism for just-in-time access requests, emergency debugging access, or temporary permissions, forcing developers to rely on manual DBA intervention even during critical incidents. The development experience is impacted by inability to create local test environments with proper authorization logic, poor debugging capabilities for authorization failures, and no way to unit test against different access scenarios.

### Alternatives: Middleware + Tooling

Instead of using database-level RLS, you can implement an authorization middleware layer that intercepts queries and enforces security policies at the application tier.

**[Open Policy Agent (OPA)](https://www.openpolicyagent.org/)**: Policies are defined in the Rego language and managed in version control systems like Git, enabling best practices such as code reviews, automated testing, and CI/CD integration.

**Bytebase**: Use Bytebase as a database access management platform to provide developers with self-service access portals. It automates approval workflows and policy generation, removing the need for DBAs to manually create and revoke temporary permissions. Bytebase also offers audit trails, break-glass access procedures, and integrates with existing identity systems.

## Summary

RLS works well for straightforward data filtering—such as `tenant_id` isolation—where database-level enforcement offers fast and reliable security baselines. It excels at applying simple predicates that map directly to database queries, without requiring external integrations or complex business logic.

However, for a production-grade multi-tenant service, a layered approach is often more scalable:

1. **RLS for Basic Tenant Isolation**
   Use RLS to enforce simple, row-level access control based on fields like `tenant_id`. This provides efficient, in-database filtering with minimal operational overhead.

2. **Application Logic + OPA for Complex Policies**
   For advanced authorization needs, integrate policy engines like Open Policy Agent (OPA) at the application layer. OPA handles dynamic logic that SQL cannot express—such as time-based access, workflow states, external API checks, or user roles—while supporting Git-based version control, automated testing, and policy simulation.

3. **Bytebase for Just-in-Time Human Access**
   For operational scenarios like production troubleshooting or emergency access, Bytebase offers a self-service portal with automated approval workflows, audit trails, and break-glass procedures. This eliminates manual DBA intervention while preserving governance and traceability.



<HintBlock type="info">

This post is maintained by Bytebase, an open-source database DevSecOps tool. We update the post every year.

</HintBlock>

| Update History | Comment            |
| -------------- | ------------------ |
| 2025/05/27     | Initial version.   |

Previously, understanding database structures required parsing lengthy SQL scripts or complex command-line interfaces, which was unintuitive and error-prone. To solve this, developers created graphical tools for visualizing database schemas, helping teams design and document databases more easily. Here, we explore four top open-source options for schema visualization in 2025.

![star-history](/content/blog/top-database-schema-diagram-tools/star-history.webp)

## DrawDB

[DrawDB](https://www.drawdb.app/)  is a free, browser-based database diagram editor with a simple drag-and-drop interface. It lets you design ER diagrams visually and export SQL scripts for MySQL, PostgreSQL, SQLite, MariaDB, and SQL Server — no account required.

**Key Features:**

- Intuitive UI with real-time collaboration
- Export diagrams as SQL or images
- Works offline (PWA-supported)

**GitHub Stats:** [30.3k stars](https://github.com/drawdb-io/drawdb), 2.1k forks

**Best For:** Quick schema design & sharing

![drawdb](/content/blog/top-database-schema-diagram-tools/drawdb.webp)
![drawdb-ui](/content/blog/top-database-schema-diagram-tools/drawdb-ui.webp)

## ChartDB

[ChartDB](https://chartdb.io/) is a smart, query-driven visualization tool that generates diagrams instantly from your database schema. It supports AI-powered DDL exports, making migrations between databases seamless.

**Key Features:**

- "Smart Query" for instant JSON schema parsing
- Supports PostgreSQL, MySQL, SQL Server, and NoSQL options
- No database credentials needed (security-focused)

**GitHub Stats:** [16.6k stars](https://github.com/chartdb/chartdb)

**Best For:** Teams managing multiple database systems

![chartdb](/content/blog/top-database-schema-diagram-tools/chartdb.webp)
![chartdb-ui](/content/blog/top-database-schema-diagram-tools/chartdb-ui.webp)

## Azimutt

[Azimutt](https://azimutt.app/) specializes in exploring large, complex schemas with advanced filtering and relationship tracking. Unlike traditional ERD tools, it handles messy real-world databases effortlessly.

**Key Features:**

- Search, filter, and trace table relationships
- Supports SQL (PostgreSQL, MySQL, SQL Server, Oracle ...) and NoSQL (MongoDB, Counchbase, SQLite ...)

**GitHub Stats:** [1.9k stars](https://github.com/azimuttapp/azimutt)

**Best For:** Enterprise-scale database documentation

![azimutt](/content/blog/top-database-schema-diagram-tools/azimutt.webp)
![azimutt-ui](/content/blog/top-database-schema-diagram-tools/azimutt-ui.webp)

## Liam ERD

[Liam ERD](https://liambx.com/) auto-generates interactive ER diagrams from existing schemas (Rails, Prisma, PostgreSQL) with zero setup. It’s ideal for visualizing large projects (100+ tables).

**Key Features:**

- Instant diagrams from schema files
- Zoom, pan, and filter for clarity
- Open-source (Apache 2.0 license)

**GitHub Stats:** [4k stars](https://github.com/liam-hq/liam)

**Best For:** Developers needing fast, no-fuss visualization

![liamerd](/content/blog/top-database-schema-diagram-tools/liamerd.webp)
![liamerd-ui](/content/blog/top-database-schema-diagram-tools/liamerd-ui.webp)

## Key Options Compared

| Tool       | Best For                  | Standout Features                     | Database Support               | GitHub Stars |
|------------|---------------------------|---------------------------------------|---------------------------------|-------------|
| **DrawDB** | Simple visualization      | Clean UI, no account needed           | MySQL, PostgreSQL, SQL Server   | 30.3k ⭐     |
| **ChartDB**| Multi-database teams      | AI-powered SQL exports                | 7+ SQL/NoSQL options            | 16.6k ⭐     |
| **Azimutt**| Complex schemas           | Advanced search & relationship maps    | SQL + MongoDB/Couchbase         | 1.9k ⭐      |
| **Liam ERD**| Auto-generated diagrams  | Zero-config setup                     | Rails, Prisma, PostgreSQL       | 4k ⭐        |

## Quick Recommendations

- **Startups/Simple Projects**: DrawDB (easiest to use)
- **Enterprise Teams**: Azimutt (handles complexity best)
- **Multi-DB Environments**: ChartDB (best for migrations)
- **Rails/Prisma Users**: Liam ERD (most automated)

## Emerging Trends

1. **AI Integration**: More tools adding smart suggestions (like ChartDB's exports)
2. **Real-Time Collaboration**: Team editing features becoming standard
3. **Broader NoSQL Support**: Tools expanding beyond relational DBs

All tools are actively maintained and free to use. For most developers, trying 2-3 options will help identify the best fit for their workflow.


<HintBlock type="info">

This post is maintained by Bytebase, an open-source database DevSecOps tool. We update the post every year.

</HintBlock>

| Update History | Comment                                                             |
| -------------- | ------------------------------------------------------------------- |
| 2024/09/11     | Initial version.                                                    |
| 2025/05/27     | 2025 Update.                                                        |
| 2025/12/04     | Add TablePlus and DBHub. Remove Outerbase (acquired by Cloudflare). |
| 2026/02/03     | 2026 Update. Update DataGrip and Vanna.ai with major new features.  |

This is a series articles about SQL Clients / SQL Editors:

1. [Open Source SQL Clients](/blog/top-open-source-sql-clients)
1. Text-to-SQL Query Tools (this one)

---

If you work with databases, SQL AI tools can significantly improve your productivity and efficiency. They help generate SQL commands automatically from natural language input and optimize query performance as functional and starter-friendly tool.

Here we gathered some of the most popular SQL AI tools (Text2SQL) on the market in 2026.

## DataGrip

JetBrains introduces an AI Assistant to its flagship SQL client [DataGrip](https://www.jetbrains.com/datagrip/).

![](/content/blog/top-text-to-sql-query-tools/datagrip.webp)

The DataGrip AI Assistant can:

1. Request queries and information using natural language.
1. Explain complex SQL such as stored procedures.
1. Optimize schema and SQL.
1. Compare DDL of two database objects.
1. Fix SQL mistakes.
1. Format and rewrite SQL.

During 2025, JetBrains significantly enhanced the AI Assistant:

- **Schema and object context**: Attach specific database objects (tables, views) to AI chat for more precise responses, not just the whole schema.
- **Execution plan analysis**: AI can explain query execution plans and suggest optimizations for better performance.
- **Cloud-based code completion**: Leverages cloud resources for more precise autocomplete, including single lines, code blocks, and entire scripts.
- **Cloud database integration**: Connect directly to AWS, Azure, and Google Cloud accounts to browse and connect to databases.
- **Free tier and local models**: A free tier offers unlimited local completions, and you can connect OpenAI-compatible local endpoints (Ollama, LM Studio) for offline use.

## TablePlus

[TablePlus](https://tableplus.com/) is considered by many as the best SQL client on Mac. It's a modern, native database management tool that supports multiple databases. It has integrated text-to-SQL AI capabilities to help developers generate queries from natural language.

![](/content/blog/top-text-to-sql-query-tools/tableplus.webp)

Unlike DataGrip which charges an extra price for its comprehensive AI Assistant features, TablePlus follows a BYOK (Bring Your Own Key) model, allowing you to pick your preferred LLM provider. While it only provides text-to-SQL generation rather than the full suite of AI features offered by DataGrip, this approach gives users more flexibility in choosing their AI backend.

![](/content/blog/top-text-to-sql-query-tools/tableplus-llm.webp)

## SQL Chat

![](/content/blog/top-text-to-sql-query-tools/sqlchat.webp)

[SQL Chat](https://www.sqlchat.ai/) is a chat-based SQL client, which uses natural language to communicate with the database to implement operations such as query, modification, addition, and deletion of the database. Instead of navigating across many UI controls, SQL chat applies a much more intuitive chat-based interface, bringing more flexible and comfortable user experience.

SQL Chat supports the following databases and will add more over time:

- MySQL
- PostgreSQL
- MSSQL
- TiDB Cloud

## Vanna.ai

![](/content/blog/top-text-to-sql-query-tools/vanna.webp)

[Vanna.ai](https://vanna.ai/) is a personalized AI SQL agent that transforms natural language questions into actionable database insights. In late 2025, Vanna released **Vanna 2.0**, a complete architectural rewrite that evolved from a simple SQL generation library into a production-ready, user-aware agent framework.

Key features of Vanna 2.0:

- **Agent-based architecture**: New Agent-based API replacing the legacy VannaBase class methods, with better support for agentic models like Claude 4.5 and GPT-5.
- **User-aware components**: Identity flows through every layer with user context automatically available in tools, SQL queries, and audit logs.
- **Enterprise security**: Row-level security with queries filtered based on user permissions, group-based access control, and comprehensive audit logging for compliance.
- **Web-first approach**: Built-in `<vanna-chat>` component and server with streaming and rich UI components.
- **NVIDIA NIM integration**: Accelerated inference using NVIDIA NIM microservices for improved performance.

The platform supports major databases including PostgreSQL, MySQL, Snowflake, BigQuery, Redshift, SQLite, Oracle, SQL Server, DuckDB, ClickHouse, and more. For LLMs, it supports OpenAI, Anthropic Claude, Google Gemini, Azure OpenAI, Ollama, and others.

## SQLAI.ai

[SQLAI.ai](https://www.sqlai.ai/) is divided into several SQL generators, each serving specific purposes:

- **Explain SQL Queries**: Offers explanations with summaries, output visualizations, and detailed query breakdowns.
- **Format SQL Query**: Formats SQL queries for improved readability and reduced error-proneness.
- **Analyze Your Data**: Allows you to upload CSV data and ask AI questions.
- **Generate SQL Query, Fix SQL Queries, Optimize SQL Query, etc.**

![](/content/blog/top-text-to-sql-query-tools/sqlai.webp)

In addition to the core generators, SQLAI.ai includes tools to facilitate your work. The available tools vary depending on the generator.

## Honorable mention

### Postgres.new

[Postgres.new](https://postgres.new/) is an WASM-based in-browser PostgreSQL sandbox with AI assistance. It allows users to operate with PostgreSQL directly in a web browser, without having to install or set up the database locally.

![](/content/blog/top-text-to-sql-query-tools/postgresnew.webp)

Postgres.new is currently in early alpha with limited functionality. It may have limitations compared to a full native PostgreSQL installation.

### DBHub (MCP Server)

Unlike standalone SQL clients, [DBHub](https://dbhub.ai) brings text-to-SQL capabilities directly into your existing development workflow through the MCP standard, eliminating the need to switch between tools.

![](/content/blog/top-text-to-sql-query-tools/dbhub.webp)

DBHub is a universal database MCP (Model Context Protocol) server that enables any MCP client such as Claude, Cursor, VS Code, and Codex to have text-to-SQL capability. It acts as a bridge between AI assistants and databases, allowing developers to use natural language to query and explore their databases directly from their development tools.

As of early 2026, DBHub has over 100K downloads and 2K GitHub stars. It supports multiple databases including PostgreSQL, MySQL, MariaDB, SQL Server, and SQLite. Key features include:

- **Custom tools**: Define reusable, parameterized SQL operations in configuration files.
- **Built-in web interface**: Visual way to execute queries, run custom tools, and view request traces without requiring an MCP client.
- **Security-first design**: Read-only mode and safety controls to prevent accidental data modifications.

Compared with other database MCP servers, DBHub comes with an admin console to view configured data sources and trace SQL requests.

![](/content/blog/top-text-to-sql-query-tools/dbhub-console.webp)

## Techniques and Benchmarks

Cloud hyperscalers are increasingly integrating Text-to-SQL capabilities across their database offerings. Google Cloud, for example, has rolled out this feature to BigQuery, Cloud SQL, and AlloyDB, and recently published [guidance](https://cloud.google.com/blog/products/databases/techniques-for-improving-text-to-sql) on effective AI prompting techniques for SQL generation. Meanwhile, the research community has developed evaluation frameworks like [BIRD-Bench](https://bird-bench.github.io/) to measure Text-to-SQL accuracy.

## Security Considerations

When Anthropic introduced MCP, the Postgres server was one of the original reference implementations. Security reviews of early MCP-based database servers have shown that simply wrapping user-supplied SQL in a read-only transaction is not sufficient if the server also accepts semicolon-delimited statements, because additional statements may execute outside the intended protection. When evaluating MCP-based database tools, prioritize implementations with robust security controls such as proper SQL parsing or allow-listing, strict read-only enforcement, and clear configuration for which databases and schemas can be accessed.

Text-to-SQL tools improve efficiency and make it easier to interact with databases. Although they use state-of-the-art LLM models, the results may sometimes be inaccurate. If you want to use them in production, make sure to double-check before you hit **RUN**.



Database schema changes are critical operations that require careful planning and execution. The ability to perform these changes safely and reliably is a key consideration when choosing a database management system. In this post, we'll compare how PostgreSQL 17 and MySQL 8 handle Data Definition Language (DDL) transactions, with a focus on atomicity and rollback capabilities.

## Understanding DDL Transactions

Before diving into the comparison, let's clarify what we mean by DDL transactions. DDL statements can be grouped together and either committed as a unit or rolled back entirely if something goes wrong.

There are two important concepts to distinguish:

1. **Transactional DDL**: The ability to include DDL statements within a multi-statement transaction block, with the option to commit or roll back all statements together.

2. **Atomic DDL**: The guarantee that individual DDL statements are atomic (all-or-nothing), but not necessarily supporting their inclusion in multi-statement transactions.

## PostgreSQL 17: True Transactional DDL

In PostgreSQL 17, DDL operations are fully transactional, meaning:

- DDL statements can be included in transaction blocks alongside DML statements
- Multiple DDL operations can be committed or rolled back as a single unit
- Savepoints can be used within transactions that include DDL statements
- If a transaction fails, all DDL changes are rolled back, leaving the database in its original state

There are only a few exceptions to this rule: operations on databases and tablespaces themselves (such as `CREATE DATABASE` or `DROP TABLESPACE`) cannot be rolled back. However, all other catalog operations are reversible.

## MySQL 8: Atomic DDL

Prior to MySQL 8, DDL operations in MySQL were not atomic at all. If a DDL statement failed partway through execution—such as an `ALTER TABLE` operation that was adding multiple columns or indexes—the database could be left in an inconsistent, partially-modified state.

MySQL 8 introduced a feature called **Atomic DDL** which represents a significant improvement over previous versions but differs fundamentally from PostgreSQL's approach.

In MySQL 8, DDL statements are atomic at the statement level, meaning:

- Individual DDL statements are either fully completed or fully rolled back
- DDL statements **implicitly commit** any active transaction before execution
- DDL statements cannot be part of a multi-statement transaction that can be rolled back
- Crash recovery ensures statement-level atomicity

MySQL's atomic DDL is implemented through a special internal `DDL_LOG` table in InnoDB that tracks the creation of files and structures during DDL execution. This log is used at commit/rollback time to clean up properly, ensuring that no orphaned files or index trees remain after a crash.

It's important to note that atomic DDL is only supported in MySQL 8 InnoDB storage engine. For tables using other storage engines, partial updates may still occur.

## Examples

To better understand these differences, let's run some DDLs that demonstrate how DDL transactions behave in both systems.

### PostgreSQL 17

Our 1st example makes all DDL operations wrap in a transaction. When we execute the `ROLLBACK` command, all tables and indexes are removed as if they were never created.

```sql
-- Start a transaction block
BEGIN;

-- Create a simple table
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    username VARCHAR(50) NOT NULL
);

-- Add an index
CREATE INDEX idx_username ON users(username);

-- Oops! We made a mistake and want to roll back all changes
ROLLBACK;

-- Verify that the table was not created
SELECT table_name FROM information_schema.tables
WHERE table_schema = 'public' AND table_name = 'users';
-- Should return no rows, as the transaction was rolled back
```

The 2nd example demonstrates how PostgreSQL allows partial rollbacks using `SAVEPOINT`, giving developers fine-grained control over schema changes.

```sql
BEGIN;

-- Create a table
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    username VARCHAR(50) NOT NULL
);

-- Create a savepoint
SAVEPOINT after_users_table;

-- Alter the table to add a column
ALTER TABLE users ADD COLUMN email VARCHAR(100);

-- Oops! We only want to roll back the column addition
ROLLBACK TO after_users_table;

-- Add a different column instead
ALTER TABLE users ADD COLUMN active BOOLEAN DEFAULT TRUE;

-- Commit the transaction
COMMIT;
```

### MySQL 8

In this MySQL example, despite wrapping the DDL statements in a transaction block, the `ROLLBACK` command does not undo the table creation. This is because each DDL statement implicitly commits the transaction before executing, making it impossible to roll back multiple DDL statements as a unit.

```sql
-- Try to use a transaction block (note: this won't work as expected for DDL)
START TRANSACTION;

-- Create a simple table
CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(50) NOT NULL
);

-- Add an index
CREATE INDEX idx_username ON users(username);

-- Try to roll back all changes (won't work for DDL statements)
ROLLBACK;

-- Verify that the table was created despite the ROLLBACK
SHOW TABLES;
-- Will show 'users' table
```

However, MySQL 8 does provide statement-level atomicity:

```sql
-- This will either create all users or none
CREATE USER 'user1'@'localhost' IDENTIFIED BY 'password1',
           'user2'@'localhost' IDENTIFIED BY 'password2';

-- This will either drop all tables or none
DROP TABLE IF EXISTS table1, table2, table3;
```

## Conclusion

Let's examine the key differences between PostgreSQL 17 and MySQL 8 in how they handle DDL transactions:

| Feature                               | PostgreSQL 17                      | MySQL 8                                                 |
| ------------------------------------- | ---------------------------------- | ------------------------------------------------------- |
| **DDL Transaction Support**           | Full transactional DDL             | Atomic DDL (statement-level only)                       |
| **Multi-statement DDL Transactions**  | Yes                                | No                                                      |
| **DDL Rollback in Transaction**       | Yes                                | No (implicit commit)                                    |
| **Atomicity of Single DDL Statement** | Yes                                | Yes (InnoDB only)                                       |
| **Crash Recovery**                    | Full transaction recovery          | Statement-level recovery                                |
| **Savepoints with DDL**               | Supported                          | Not supported                                           |
| **Exceptions**                        | Database and tablespace operations | Database directory removal not part of atomic operation |
| **Implementation Mechanism**          | Write-Ahead Log (WAL)              | DDL_LOG in InnoDB                                       |

PostgreSQL's transactional DDL provides a higher level of safety for complex schema migrations. By wrapping multiple related changes in a transaction, administrators can ensure that the database remains in a consistent state, even if something goes wrong during the migration process. In contrast, MySQL 8 introduces atomic DDL at the statement level, meaning each individual DDL statement is executed as an all-or-nothing operation. While this is a notable improvement over earlier versions of MySQL, it still does not support multi-statement DDL transactions.

## Postgres vs MySQL Comparison Series

- [Overall comparison](/blog/postgres-vs-mysql)
- [Indexing Options](/blog/postgres-vs-mysql-indexing-options)
- [JSON Support](/blog/postgres-vs-mysql-json-support)
- [Online Index Creation](/blog/postgres-vs-mysql-online-index-creation)

## References

1. PostgreSQL Wiki: [Transactional DDL in PostgreSQL: A Competitive Analysis](https://wiki.postgresql.org/wiki/Transactional_DDL_in_PostgreSQL:_A_Competitive_Analysis)

1. MySQL Documentation: [Atomic Data Definition Statement Support](https://dev.mysql.com/doc/refman/8.4/en/atomic-ddl.html)

1. MySQL Blog: [Atomic DDL in MySQL 8.0](https://dev.mysql.com/blog-archive/atomic-ddl-in-mysql-8-0/)

1. MySQL Documentation: [Statements That Cannot Be Rolled Back](https://dev.mysql.com/doc/refman/8.2/en/cannot-roll-back.html)


The
Bytebase Blog

Explore the standard for database development

Solutions & Platform

Comparisons

Legal

Resources

Company