Postgres SQL review tools compared: SQLFluff for style, Squawk for migration safety, plpgsql_check and pgTAP, and where Bytebase fits as the approval layer.

Top Dynamic Data Masking Tools in 2026

Zero trust for databases extends identity and network controls to SQL statements, query results, data changes, and schema changes.

Zero Trust for Databases: From Access Control to SQL Control

Snowflake and the data warehouses can tag any database object with structured metadata and drive masking from it. Almost no production database can. In the LLM era, that inline, self-contained context is exactly what agents need.

Object Tagging: The AI Feature Almost Every Production Database Skipped

Database governance lives upstream, on the production database. Here is how to actually govern the source: reviewed changes, scoped access, codified policy, and audit where the data is born.

How to Govern Data at the Source: A Guide to Upstream Database Governance

Data governance and database governance are four letters apart and constantly conflated. They are different disciplines, owned by different teams, solved by different tools. Here is the dividing line.

Data Governance vs. Database Governance: The Difference Is the Base

PopSQL shuts down on September 1, 2026. Compare the top PopSQL alternatives for team SQL editing, dashboards, and governed database access before you migrate.

Top PopSQL Alternatives 2026: Where to Migrate Before the Shutdown

Money software is judged not on whether the feature works, but on what the database can prove eighteen months later. Fintech database governance through three principles: no invented data, no lost data, no trust.

Database Governance for Fintech: Guarding the Ledger

PostgreSQL has no ADD COLUMN ... AFTER. The reason one little number in a system catalog turned a "simple" feature into a decade-long engineering saga, and what you can do about it today.

Why It's So Hard to Add a Column in the Middle of a PostgreSQL Table

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)

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

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

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

A practical look at what SOX Section 404 expects from database changes: the four ITGC domains, the six questions auditors actually ask, and how to make compliance evidence a byproduct of your workflow.

Database Change Management for SOX Compliance

A look at 10 data management tools developers and data engineers actually use in 2026: GUI clients, schema migration, pipelines, and analytics, with pricing for each.

Top 10 Data Management Tools in 2026

The best SQL editors built exclusively for PostgreSQL: what each one is good at, who it fits, and when a Postgres-only tool beats a multi-database client.

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

A practical look at the database deployment tools DevOps teams actually use in 2026, sorted by how each one defines, applies, and coordinates schema changes.

Database Deployment Tools for DevOps Teams in 2026

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

How to run MySQL schema migrations without blocking queries or causing downtime, covering the MySQL-specific behaviors that bite in production and the tools that work around them.

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 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

Six open-source PostgreSQL backup tools compared for 2026, with the language, license, interface, and best-fit use case for each, plus a note on which ones are still maintained.

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

A look at the open-source ways to add authentication and authorization to a Postgres app in 2025, from all-in-one platforms to libraries, identity servers, and the minimalist JWT-to-RLS pattern, with a "best for" note on each.

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

Compare the top free, open-source database schema diagram tools in 2026 (DrawDB, ChartDB, Azimutt, and Liam ERD) by database support, workflow, and project momentum.

Top 4 Free, Open Source Database Schema Diagram Tools in 2026

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

Top 6 Text-to-SQL Query Tools in 2026

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

Top TypeScript ORM 2026

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 in 2026: Aurora, Cloud SQL, AlloyDB, Azure, DigitalOcean, Aiven, TigerData, and the serverless Postgres providers, with cost comparisons.

RDS Alternatives in 2026

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 2026: Pricing Comparison

Database governance controls how production databases are changed and accessed; data governance catalogs what lands downstream. The terms are conflated in every search, so this post covers the top open-source tools on both sides of the line.

Top Open Source Database Governance Tools in 2026

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

Compare the price of the mainstream managed MySQL hosting providers

MySQL Hosting Options in 2026: Pricing Comparison

A comprehensive guide to the best open-source Kubernetes cluster management tools in 2025, including Argo CD, Karmada, Sveltos, and Plural.

Top 4 Open Source Kubernetes Cluster Management Tools in 2025

Review the state of the Golang ORM and query builder in 2026

Choose the Right Golang ORM or Query Builder in 2026

Overview of MySQL 9 features with spicy comments

What's New in MySQL 9 - a DBA's Perspective

SQL clients makes it safer and easier to manage databases. In this post, we are taking a look at open source SQL clients options for you to try in 2024.

Top Open-Source SQL Parsers in 2025

A comprehensive reference guide to standard port numbers used by popular database systems in 2025

Common Database Port Numbers in 2025

Explore the leading Terraform UI tools of 2026 that enhance IaC workflows with visualization, collaboration, and governance features to streamline infrastructure management.

Top 4 Terraform UI Tools 2026

A comprehensive guide to the best free and open-source PostgreSQL EXPLAIN tools for query performance analysis, including built-in extensions, online visualizers, and integrated GUI solutions.

Top Free, Open Source Postgres Explain Tool to Analyze Database 2025

Top open-source Kubernetes dashboard solutions include K9s, Lens, and KubeDashboard.

Top Free, Open Source Kubernetes Dashboard in 2026

In this post, we will review the top 5 open source Terraform tools for 2025.

Top 5 Open Source Terraform Tools for 2025

A Postgres schema compare tool diffs and synchronizes schemas between PostgreSQL databases. This 2026 guide reviews the top 6 tools — pg-schema-diff, Atlas, Liquibase, pgAdmin, Navicat, and Bytebase — and how to choose.

Top 6 Open Source Infrastructure as Code (IaC) Tools 2025

How to Become a Platform Engineer in 6 months?

SQL editor with built-in AI streamlines database management, making SQL development faster, more accurate, and accessible to users of all skill levels.

Top 3 Free SQL Editors with Built-in AI

An extensive list of PostgreSQL SQL Review and Style Guide.

PostgreSQL SQL Review and Style Guide

Compare the best SQL Server monitoring tools for 2026 — free and paid. Includes SSMS built-in SQL monitors, open-source MSSQL monitoring tools (DBA Dash, SQLWATCH, Opserver), and commercial SQL performance monitoring solutions (Redgate, Datadog).

Top SQL Server Monitoring Tools: Best SQL Performance Monitors in 2026

The open source, self-hostable, web-based SQL editors compared honestly, with per-tool verdicts and a fresh repository-activity check.

Top 5 Open Source, Online SQL Editors You can Self-host

The top database DevOps tools in 2026 by category: CI/CD, SQL lint, backup, data masking, observability, access management, secrets, and all-in-one.

Top Database DevOps Tools in 2026

Introduce the advanced tools for platform engineering. Covering CD, security, workflow orchestration, database development workflow, and internal development portal.

How to Pick Platform Engineering Tools in 2025 - Advanced Guide

Introduce the essential tools for platform engineering. Covering code hosting, CI/CD, observability, resource provisioning, and secret management.

How to Pick Platform Engineering Tools in 2025 - Essential Guide

Bastion gates connections. ITSM gates approval. PAM gates credentials. Three layers, three tools, one gap at execution — and what an integrated platform replaces.

Securing Database Change: From Bastion to Integrated Platforms

How OpenAI and DeepSeek designs SSN database schema.

OpenAI vs. DeepSeek: SSN Database Schema Design

DevSecOps tools empower teams to seamlessly integrate security into every phase of the software development lifecycle, fostering the adoption of DevSecOps practices.

Top DevSecOps Tools for 2025

What happened in the database tooling landscape in 2024.

Database Tools in 2024: A Year in Review

Some of the craziest database security vulnerabilities uncovered in DBAs' career

Database security vulnerabilities are the craziest

Due to Docker's recent requirement for a paid subscription for professional use, people began searching for alternatives. Right alternatives for you will depend on your specific needs and requirements.

Top 4 Free Docker Desktop Alternatives 2026

What are the top Postgres extensions you may need to enhance your Postgres instance in 2026.

Why Managed Database Service is not Enough

Six levels of database automation, named after the autonomous-driving framework. From L0 manual SQL to L5 self-healing — and where most teams plateau.

The 6 Levels of Database Automation

When team wants to enforce a process for database change management. A quick approach is to reuse their existing ITSM system such as Jira. Let's review how a typical Jira workflow looks like and its inherent limitations.

Hope Is Not a Strategy: Why Jira Falls Short for Database Change

A list of features I wish PostgreSQL had. It is mainly around improving development workflow and inspired by Git. While acquiring Git-like behavior is challenging in database because of the stateful nature.

Features I wish PostgreSQL had as a developer

In this post, we are reviewing several open-source GitOps tools.

Top Open Source GitOps Tools in 2025

When schema migration outage happens, who should be more responsible in order to prevent future incidents?

Schema Migration Outage: Author or Reviewer's Fault?

The "Modern Snowflake Stack" refers to the set of technologies and tools built around Snowflake for data ingestion, transformation, security, and analytics. First mapped in early 2024, refreshed for 2026 after a wave of mergers and acquisitions reshuffled nearly every layer.

Modern Snowflake Stack in 2026

What are the top open source MySQL schema migration tools in 2026 - Skeema, Liquibase, Flyway, and Bytebase compared.

Top Open Source MySQL Migration Tools in 2026

This article explores leading database security tools designed to shield your data from varied risks.

Top Database Security Tools

A comparison of the top 5 MySQL GUI clients in 2026: MySQL Workbench, DBeaver, TablePlus, Beekeeper Studio, and Navicat.

Top 5 MySQL GUI Clients in 2026

The top open source Postgres migration tools in 2026: Flyway, Liquibase, Atlas, Sqitch, pgroll, graphile-migrate, pgschema, and Bytebase compared.

How many DBAs should a company hire

DORA recently released its annual State of DevOps 2023 report. Bytebase is a Database CI/CD tool for DBAs and DevOps teams, and we are diving deep into the State of DevOps Report.

Notes on the DORA 2023 State of DevOps Report

DataGrip is a database IDE developed by JetBrains and closely integrated with the JetBrains ecosystem. If you prefer a dedicated database GUI, here are the top DataGrip alternatives in 2026.

Top DataGrip Alternatives 2026

If you work exclusively with MySQL, MySQL Workbench is an excellent choice for a database GUI, but if you work with multiple databases, you need to look elsewhere. This article highlights five database GUI alternatives for MySQL Workbench.

Top MySQL Workbench Alternatives 2026

pgAdmin is the default Postgres GUI, but it is not the only one. Here are the top pgAdmin alternatives in 2026.

Top pgAdmin Alternatives 2026

Navicat is a long-established database GUI, but it falls short in multi-user scenarios where team collaboration and centralized control are needed. Here are the top Navicat alternatives in 2026.

Top Navicat Alternatives 2026

DBeaver is one of the most popular database management tools. If it doesn't fulfill your requirements or you want to try something new, here are the top DBeaver alternatives in 2026.

Top DBeaver Alternatives 2026

A Postgres GUI client gives you a visual interface to query, design, and administer PostgreSQL — instead of doing everything from psql. Here are the 7 most useful in 2026, with the trade-offs that decide which one fits your workflow.

Understanding Google Cloud SQL Pricing

A MySQL schema compare tool diffs and synchronizes schemas between MySQL databases. This 2026 guide reviews the top 6 common tools in this category and how to choose.

Top 6 MySQL Schema Compare Tools to Diff and Sync Databases in 2026

Database schema migration have come a long way, from CLI to GUI, and all the way to GitOps/Database-as-Code. Let's review the state-of-the-art of database schema change / migration tools in 2026.

Top Database Schema Migration Tools to Avoid Change Outage 2026

What happened in database industry in 2022.

Database Review 2022 and 2023 Prediction

The best free SQL clients and database management software in 2026. Compare DBeaver, Beekeeper Studio, DbGate, HeidiSQL, and Bytebase — open-source SQL GUI tools for Mac, Windows, and Linux.

Top 5 Free, Open Source SQL Clients and Database Management Tools (2026)

To manually spin up several different kinds (and versions) of database instances for testing can be gruesome. Here are some free tools to help you start a local database instance on Mac.

Top 3 Free Tools to Start a Local Database Instance on Mac

Real talk on whether strict SQL review and schema conventions actually help — with answers from working developers and DBAs.

Is SQL Review Necessary? Real Talk From Developers

We wonder if ChatGPT can help us in the field of database administration, and we dug deep into some toolings that have incorporated ChatGPT to make our life easier.

A (Non-Exhaustive) Summary of ChatGPT Enhanced Database Tools

From the SQLite-insipred DuckDB to the real Snowflake challenger and the Docker for data.

MotherDuck, from SQLite to the Docker for Data

The idea of codifying database schema changes (aka schema migration) is not new. While we are observing an accelerated trend of embracing Database as Code (DaC) across the industry. In this blog, we will review the state-of-the-art in the Database as Code landscape and share our own insight into the current and future trends in this space.

The Database as Code Landscape

This is the first of the DDD series, consisting of 10 stories of DBA & Database & developer.

DBA, Database and Developer - The Decameron

What happened in database industry in 2021. OLAP (Snowflake, Databricks, ClickHouse, Firebolt, ClickHouse), OLTP (PostgreSQL, PlanetScale, SQLite) and open source.

Database Review 2021 and 2022 Prediction


Extensibility is PostgreSQL's DNA, lies in its [original design](https://dsf.berkeley.edu/papers/ERL-M85-95.pdf).

![design](/content/blog/top-postgres-extension/design.webp)

This design philosophy grants PostgreSQL a lot of unique capabilities, one of them is its extension system. With [Postgres extension](https://www.postgresql.org/docs/current/extend-extensions.html), 3rd parties can extend the Postgres capabilities without touching any Postgres core.

Today most production Postgres deployments run some extensions. Below we present those most commonly used ones.

| Extension                                 | Capability                      |
| ----------------------------------------- | ------------------------------- |
| [PostGIS](#postgis)                       | Process geospatial data         |
| [pg_stat_statements](#pg_stat_statements) | Collect execution stats         |
| [postgres_fdw](#postgres_fdw)             | Query external PostgreSQL data  |
| [uuid-ossp](#uuid-ossp)                   | Generate UUID                   |
| [pgcrypto](#pgcrypto)                     | Cryptographic functions         |
| [pg_cron](#pg_cron)                       | Schedule job inside database    |
| [pgAudit](#pgaudit)                       | Audit Logging                   |
| [pg_repack](#pg_repack)                   | Remove bloat with minimal locks |
| [timescaledb](#timescaledb)               | Process time-series data        |
| [pgvector](#pgvector)                     | Process vectorized data         |

## PostGIS

[PostGIS](http://postgis.net/) extends the PostgreSQL by adding support storing, indexing and querying geographic data. PostGIS is the most complex Postgres extension and a testimony of the Postgres powerful extension system.

To find the nearest city to a given point:

1. Say we have the following table of cities with their locations represented by points. Note, the `location` column has a GEOMETRY type which is provided by the PostGIS extension.

   ```sql
   CREATE TABLE cities (
   name TEXT,
   location GEOMETRY(Point, 4326)
   );
   ```

1. To find the nearest place to a given point, you can use the ST_Distance function to calculate the distance between the point and each place in the table, and then sort the results by distance. For example, the following command finds the nearest city to the point (-74.005941, 40.712784), which is the location of New York City:

   ```sql
   SELECT name, ST_Distance(location, ST_SetSRID(ST_MakePoint(-74.005941, 40.712784), 4326)) AS distance
   FROM cities
   ORDER BY location <-> ST_SetSRID(ST_MakePoint(-74.005941, 40.712784), 4326)
   LIMIT 1;
   ```

This query calculates the distance between each city in the cities table and the point (-74.005941, 40.712784), and sorts the results by distance using the `<->` operator. The LIMIT 1 clause returns only the nearest city.

Note that for a GEOMETRY column in SRID 4326, ST_Distance returns the distance in degrees, not meters. To get meters, cast to the GEOGRAPHY type (`location::geography`) or use ST_DistanceSphere.

## pg_stat_statements

[pg_stat_statements](https://www.postgresql.org/docs/current/pgstatstatements.html) provides a means for tracking planning and execution statistics of all SQL statements executed by a server. When pg_stat_statements is active, it tracks statistics across all databases of the server. The statistics gathered by the module are made available via a view named `pg_stat_statements`.

Note that the pg_stat_statements extension only tracks queries that have been executed since it was enabled. If you want to track all queries, you should enable the extension at server start-up by adding the following line to your postgresql.conf file:

```ini
shared_preload_libraries = 'pg_stat_statements'
```

To find the top 10 queries by total execution time:

```sql
SELECT query, total_exec_time
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;
```

## postgres_fdw

[postgres_fdw](https://www.postgresql.org/docs/current/postgres-fdw.html) can be used to access data stored in external PostgreSQL servers. `postgres_fdw` is the successor of the old `dblink` extension. `postgres_fdw` provides more transparent and standards-compliant syntax for accessing remote tables, and can give better performance in many cases.

With `postgres_fdw`, you can query other Postgres database.

1. Create a new database that you want to query. For example, let's create a database named my_other_database:

   ```sql
   CREATE DATABASE my_other_database;
   ```

1. Connect to the database where you want to create the foreign table (in this example, we'll use the default postgres database).

1. Create a user mapping for the user that will access the remote database. For example, if you want to use the same user that you are currently connected as, you can run the following command:

   ```sql
   CREATE USER MAPPING FOR current_user
   SERVER my_other_database
   OPTIONS (user 'postgres', password '');
   ```

1. Create a foreign server definition using the postgres_fdw extension.

   ```sql
   CREATE SERVER my_other_database_server
   FOREIGN DATA WRAPPER postgres_fdw
   OPTIONS (dbname 'my_other_database');
   ```

   This command creates a server definition named `my_other_database_server` using the postgres_fdw foreign data wrapper and the dbname option set to `my_other_database`.

1. Create a foreign table definition in the local database that maps to a table in the remote my_other_database database.

   ```sql
   CREATE FOREIGN TABLE my_other_table (
   id INTEGER,
   name TEXT
   )
   SERVER my_other_database_server
   OPTIONS (schema_name 'public', table_name 'my_table');
   ```

   This command creates a foreign table named my_other_table in the local database that maps to a table named my_table in the public schema of the my_other_database database.

1. Use the foreign table in queries just like you would a regular table.

   ```sql
   SELECT * FROM my_other_table WHERE id = 1;
   ```

   You can also join the foreign table with local tables in your queries, just like you would with regular tables.

Note that when using postgres_fdw to query a remote database on the same PostgreSQL instance, you may need to adjust the postgresql.conf file and restart the PostgreSQL server to enable access to the pg_hba.conf file for the other database.

## uuid-ossp

[uuid-ossp](https://www.postgresql.org/docs/current/uuid-ossp.html) provides functions to generate universally unique identifiers (UUIDs) using one of several standard algorithms. To be honest, PostgreSQL 18 makes this extension largely obsolete: core now has `gen_random_uuid()` for version 4 and a native `uuidv7()` for time-ordered UUIDs with better index locality, which covers the two versions people actually want. It stays on this list because 18 is still new and most fleets run older majors; if you are on 18+, you probably only need `uuid-ossp` for the deterministic v3/v5.

To generate a version 5 UUID:

```sql
SELECT uuid_generate_v5(uuid_ns_url(), 'example.com');
```

This command generates a UUID version 5 based on the namespace identifier for URLs (uuid_ns_url()) and the name string 'example.com'. The output will look something like this: `f1f5d9f0-2a4c-5f24-9536-3f1f69e68a7e`.

You can also create your own namespace identifier using the uuid-ossp function uuid_ns_create().

```sql
SELECT uuid_ns_create('example');
```

This command creates a namespace identifier using the name 'example' and returns it as a UUID.

You can then use this namespace identifier with uuid_generate_v5() to generate UUIDs based on that namespace and a name string.

Note that UUID version 5 is deterministic: the same namespace and name always produce the same UUID, which makes it useful for generating stable identifiers from external keys.

## pgcrypto

[pgcrypto](https://www.postgresql.org/docs/current/pgcrypto.html) is a PostgreSQL extension that provides cryptographic functions and capabilities directly within the database. It enhances data security by allowing various cryptographic operations to be performed within SQL queries.

1. Hashing

   ```sql
   SELECT digest('data to hash', 'sha256');
   ```

1. Encryption / decryption

   ```sql
   SELECT pgp_sym_encrypt('my secret data', 'my passphrase');
   SELECT pgp_sym_decrypt(encrypted_data, 'my passphrase');
   ```

1. Password hashing with salt

   ```sql
   INSERT INTO users (username, password_hash)
   VALUES ('bob', crypt('foobar123', gen_salt('xyz')));
   ```

1. Public key cryptography

   ```sql
   SELECT pgp_pub_encrypt('data', dearmor('-----BEGIN PGP PUBLIC KEY BLOCK----- ...'));
   SELECT pgp_pub_decrypt(encrypted_data, dearmor('-----BEGIN PGP PRIVATE KEY BLOCK----- ...'));
   ```

## pg_cron

[pg_cron](https://github.com/citusdata/pg_cron) is a simple cron-based job scheduler that runs inside the database as an extension. It uses the same syntax as regular cron, but it allows you to schedule PostgreSQL commands directly from the database.

The schedule uses the standard cron syntax.

![cron](/content/blog/top-postgres-extension/cron.webp)

1. Create a new cron job by running the following command

   ```sql
   SELECT cron.schedule('0 0 * * *', 'INSERT INTO my_table SELECT * FROM my_other_table');
   ```

1. Verify that the cron job has been created

   ```sql
   SELECT jobid, schedule, command FROM cron.job;
   ```

1. View the status of running and recently completed job

   ```sql
   select * from cron.job_run_details order by start_time desc limit 5;
   ```

## pgAudit

[pgAudit](https://github.com/pgaudit/pgaudit) is an extension for PostgreSQL that provides detailed session and/or object audit logging via the standard logging facility provided by PostgreSQL. It is designed to help database administrators and developers meet security and compliance requirements by providing detailed information on database activities.

It helps in meeting regulatory requirements like GDPR, HIPAA, SOX, and others by providing an audit trail of database activity.

```sql
-- Usage
SET pgaudit.log = 'read, ddl';

CREATE TABLE account
(
    id INT,
    name TEXT,
    password TEXT,
    description TEXT
);

INSERT INTO account (id, name, password, description)
             VALUES (1, 'user1', 'HASH1', 'blah, blah');

SELECT * FROM account;
```

```sql
-- Output
AUDIT: SESSION,1,1,DDL,CREATE TABLE,TABLE,public.account,create table account
(
    id int,
    name text,
    password text,
    description text
);,<not logged>
AUDIT: SESSION,2,1,READ,SELECT,,,select *
    from account,,<not logged>
```

## pg_repack

[pg_repack](https://github.com/reorg/pg_repack) rebuilds bloated tables and indexes online. The built-in answer to bloat, `VACUUM FULL`, takes an exclusive lock for the whole rewrite; pg_repack builds a fresh copy of the table in the background, replays the writes that arrived meanwhile, and swaps the tables with only a brief exclusive lock at the end.

1. Install the extension in the target database

   ```sql
   CREATE EXTENSION pg_repack;
   ```

1. Repack a bloated table from the command line

   ```shell
   pg_repack --dbname=mydb --table=my_bloated_table
   ```

The table needs a primary key or a NOT NULL unique index, and the rebuild temporarily needs roughly twice the table's disk space. Those constraints aside, it is the standard tool for reclaiming space from update-heavy tables without a maintenance window.

## timescaledb

[timescaledb](https://www.tigerdata.com/) provides optimized storage and querying of time-series data. The company behind it renamed from Timescale to TigerData in 2025; the extension keeps its name.

1. Create a hypertable

   A hypertable is a special type of table in TimescaleDB that is designed for storing and querying time-series data. You can create a hypertable using the CREATE_HYPERTABLE function.

   ```sql
   CREATE TABLE sensor_data (
   time TIMESTAMP NOT NULL,
   value FLOAT NOT NULL
   );
   SELECT create_hypertable('sensor_data', 'time');
   ```

1. Insert some data into the sensor_data table

   ```sql
   INSERT INTO sensor_data (time, value)
   VALUES
   ('2023-07-01 00:00:00', 10.0),
   ('2023-07-01 01:00:00', 15.0),
   ('2023-07-01 02:00:00', 20.0);
   ```

1. Query the data

   TimescaleDB provides a number of optimized functions for working with time-series data, such as time_bucket for aggregating data into time intervals. For example, to calculate the average value for each hour of data, you can run the following query:

   ```sql
   SELECT time_bucket('1 hour', time) AS hour, AVG(value) AS avg_value
   FROM sensor_data
   GROUP BY hour;
   ```

## pgvector

[pgvector](https://github.com/pgvector/pgvector) stores embedding vectors next to your relational data and performs similarity search over them. It is the reason Postgres became the default database for AI applications: the embeddings live in the same database as the rows they describe, with the same transactions and backups.

To get the nearest neighbors to a vector:

1. Create a new table with a vector column

   ```sql
   CREATE TABLE items (id bigserial PRIMARY KEY, embedding vector(3));
   ```

1. Insert vectors

   ```sql
   INSERT INTO items (embedding) VALUES ('[1,2,3]'), ('[4,5,6]');
   ```

1. Query the nearest neighbors to a vector

   ```sql
   SELECT * FROM items ORDER BY embedding <-> '[3,1,2]' LIMIT 5;
   ```

## Summary

Postgres extension is a key differentiator from its main alternative MySQL. If the business requires geospatial processing, then Postgres is the only choice thanks to the PostGIS extension. And the AI era settled the vector question: pgvector is the de facto standard, and it is a big part of why every AI application seems to ship with a Postgres database underneath.



> If you don't monitor Postgres, you are not serious.

It's year 2026 and Postgres keeps the momentum. [pgvector](https://github.com/pgvector/pgvector) made it the default database for AI applications, and the warehouse giants paid up for Postgres vendors (Databricks bought [Neon](https://neon.com/), Snowflake bought Crunchy Data). More Postgres in production means more Postgres to watch. This post reviews the tools and best practices for monitoring your Postgres database.

## Open-source Tools

### pg_stat_statements

The first thing is to enable the `pg_stat_statements` extension.

```sql
CREATE EXTENSION pg_stat_statements;
```

`pg_stat_statements` tracks planning and execution statistics of all SQL statements executed by a server. It's also a prerequisite for other more advanced monitoring solutions.

```shell
psql=# SELECT query, calls, total_exec_time, rows, 100.0 * shared_blks_hit /
               nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent
          FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 5;
-[ RECORD 1 ]---+--------------------------------------------------​------------------
query           | UPDATE pgbench_tellers SET tbalance = tbalance + $1 WHERE tid = $2
calls           | 3000
total_exec_time | 20756.669379
rows            | 3000
hit_percent     | 100.0000000000000000
```

### Prometheus Postgres Exporter

[Prometheus Postgres Exporter](https://github.com/prometheus-community/postgres_exporter) extract Postgres database metrics and store them in Prometheus. From there, you can use Prometheus Alertmanager to configure alerting rules and use Grafana to create dashboards.

## Proprietary Solutions

### pganalyze

![pganalyze](/content/blog/top-postgres-monitoring-tools/pganalyze.webp)

[pganalyze](https://pganalyze.com/) is a Postgres specific observability service. It provides in-depth SQL tuning and performance monitoring. Pricing is per database server, with plans starting at $149 per month.

### DataDog

![datadog](/content/blog/top-postgres-monitoring-tools/datadog.webp)

DataDog provides [Postgres Database Monitoring](https://docs.datadoghq.com/database_monitoring/setup_postgres/selfhosted/). Its Postgres monitoring is not as extensive as pganalyze. DataDog's advantage is its integration with the entire application stack and the CI/CD pipeline. The price starts at $70 per database server per month.

### Other Options

- [pgDash](https://pgdash.io/) has a similar feature set and pricing point to pganalyze. pgDash looks less polished. On the other hand, pgDash offers self-hosted option for all plans, whereas pganalyze only offers self-hosted option for the Enterprise plan.

  ![pgdash](/content/blog/top-postgres-monitoring-tools/pgdash.webp)

- [SolarWinds Database Performance Monitor (DPM)](https://www.solarwinds.com/database-performance-monitor) also provides Postgres database performance solution. Its technology comes from the VividCortex acquisition. It's cloud-only with a steep, enterprise-oriented price.

## Best Practices

### Monitor Transaction ID Wraparound

Due to PostgreSQL's MVCC implementation, it has an infamous [transaction ID wraparound](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) risk. When this happens, it will render the entire database unavailable, see some past incidents $[Sentry](https://blog.sentry.io/transaction-id-wraparound-in-postgres/), [Mailchimp](https://mailchimp.com/what-we-learned-from-the-recent-mandrill-outage/), [Figma](https://www.figma.com/blog/post-mortem-service-disruption-on-january-21-22-2020/)$. Every capable Postgres monitoring service and database service provider can check this risk:

- [pganalyze checks every 30 minutes](https://pganalyze.com/docs/checks/vacuum/txid_wraparound)
- [Implement an Early Warning System for Transaction ID Wraparound in Amazon RDS for PostgreSQL](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/)
- [GCP Cloud SQL high-transaction-ID-utilization recommender](https://cloud.google.com/sql/docs/postgres/recommender-high-transactionid-utilization)

### Monitoring Locks

Use [pg_locks](https://www.postgresql.org/docs/current/view-pg-locks.html) view to find any lock problems. You can find connections that have held locks for a long time as well as connections that have waited too long to acquire the lock.

You should also consider enabling [log_lock_waits](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-LOCK-WAITS).

### Avoid Blocking Operations

It's always a good practice to set [lock_timeout](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-LOCK-TIMEOUT) on the user.

When making DDL changes, try to use non-blocking statements. e.g. add index with [CONCURRENTLY](https://www.postgresql.org/docs/current/sql-createindex.html), add constraint with [NOT VALID](https://www.postgresql.org/docs/current/sql-altertable.html#SQL-ALTERTABLE-DESC-ADD-TABLE-CONSTRAINT).

<HintBlock type="info">

You can configure [SQL Review](https://docs.bytebase.com/sql-review/overview/) in Bytebase and detect such anti-patterns.

</HintBlock>

### Use a Cloud Postgres Service Provider

Every managed Postgres provider ships basic monitoring out of the box, and to be honest, for most teams that alone justifies not self-hosting. There are more options at more price points than ever; we keep a [running comparison of the Postgres hosting providers and their pricing](/blog/postgres-hosting-options-pricing-comparison/).

If you must self-host for budget or compliance reasons, start with Prometheus + Grafana, and upgrade to pganalyze or Datadog once the business can pay for it. Buy the monitoring before you need it. The wraparound incident does not wait for your procurement cycle.

---

A comprehensive monitoring solution can be intimidating. We try to provide actionable suggestions to companies from different stages. Please let us know if you have other monitoring tools and best practices worth sharing to herd the elephant.



Compared to the self-host option, teams pay 30% ~ 100% markup for the managed database service, hoping it can take care of the operational burdens.
While managed database service does reduce the operational cost, it's not enough. Let's illustrate this by a simple example.

## How to revert a single-row update

All mainstream managed database services provide disaster recovery capability. Take [AWS RDS](https://aws.amazon.com/rds/features/backup/)
as an example, it offers both normal restore and PITR (Point-in-time Restores).

![_](/content/blog/why-managed-database-service-is-not-enough/rds-br.webp)

However, neither is suitable to revert a single-row update. Because it would revert not only that change, but also other
valid changes.

## Managed database service alone is not enough

Managed database service takes care of the **infrastructure challenges**:

- Provisioning
- Scaling
- Disaster recovery
- Monitoring

On the other hand, developers still face a lot of **workflow challenges**:

- How to propagate the change from dev, test to staging, prod.

- How to roll back changes.

- How to spot and tune the slow query.

- How to copy the production data to the testing environment for development.

Additionally, security engineers will emphasize the necessity of sanitizing data in advance. They also require assurance that all data access is properly controlled and meticulously recorded to maintain security and compliance.

## How to address workflow challenges

There are 3 angels to tackle the workflow challenges.

1. **Managed database service**

   - For MySQL, there is [PlanetScale](https://planetscale.com/) offering a full suite of built-in capabilities.

   ![_](/content/blog/why-managed-database-service-is-not-enough/planetscale-tech.webp)

   - For Postgres, [Neon](https://neon.tech/) provides instant branching.

   ![_](/content/blog/why-managed-database-service-is-not-enough/neon-branching.webp)

1. **Application platform**

   [Supabase](https://supabase.com/) also debuted a branching feature.

1. **Tooling**

   If teams want to avoid vendor lock-in, they would adopt database tools working with a variety of vanilla database systems.

   - To coordinate database changes, [Jira is a typical option with apparent drawbacks](/blog/use-jira-for-database-change/).

   - To sanitize production data and synthesize data for development. There are [Snaplet](https://www.snaplet.dev/) and [Neosync](https://www.neosync.dev/).

   <HintBlock type="info">

   Bytebase is also a database tool providing change management, database access control, dynamic data masking for all mainstream databases.

   </HintBlock>

## Summary

The database development lifecycle involves multiple key roles, including developers, DBAs, security engineers, and platform engineers. Traditional managed database services primarily address infrastructure needs, leaving many workflow challenges unresolved. These challenges must be addressed either through enhanced capabilities of the managed database services, application platforms, or third-party tools to ensure a comprehensive solution.



Database automation manages database tasks with minimal human intervention. Schema changes. Deployments. Access provisioning. Audit. The result: fewer errors, consistent policy, DBAs working on architecture instead of approving every `ALTER TABLE`.

Six levels, named after the autonomous-driving framework. Each level removes a class of manual work and exposes the next bottleneck.

## The 6 levels at a glance

| Level  | Name              | What's automated                               | What still needs a human | Typical tooling                |
| ------ | ----------------- | ---------------------------------------------- | ------------------------ | ------------------------------ |
| **L0** | No automation     | Nothing                                        | Everything               | Direct DB clients              |
| **L1** | Ticketing         | Request, approval, audit trail                 | Execution, review        | Jira, ServiceNow + DB client   |
| **L2** | Version controlled | Schema history, change scripts                | Deployment               | Git + migration files          |
| **L3** | Streamlined       | Deployment via CI/CD                           | Cross-tool stitching     | Liquibase, Flyway, CI runner   |
| **L4** | Integrated        | Change + ad-hoc access + audit in one platform | Strategic decisions      | Bytebase, equivalent platforms |
| **L5** | Fully automated   | End-to-end including self-healing              | Oversight only           | Aspirational                   |

![roaring-dba](/content/blog/_shared/roaring-dba.webp)

## Level 0 — No Automation

**Level 0 is when every database task is done by hand**, with no system between the operator and the database. Most teams never officially leave it. Higher-level tooling accumulates on top while one-off operations stay manual underneath.

- **Manual changes** — DBAs run SQL from a database client.
- **No version control** — no history of who changed what when.
- **Permission sprawl** — access granted by hand, outliving its reason.
- **No audit trail** — reconstructing what happened needs log forensics.

## Level 1 — Ticketing

**Level 1 is when a ticketing system gates database changes** — Jira, ServiceNow, or similar. The change itself is still executed manually. Most organizations sit here. The system records the request, approval, and audit trail. It does not prevent a typo from reaching production.

- [Ticketing system](/blog/use-jira-for-database-change/) tracks the request and decision.
- Approval gates the change.
- Approver hands the ticket to a DBA, who opens a client and runs the SQL.
- Audit lives in the ticket. Searching across many tickets is hard.

## Level 2 — Version Controlled

**Level 2 is when schema changes live in version control** alongside application code, as migration files committed to Git. Teams that have adopted DevOps for application code reach this level for the database next.

- Schema and migrations tracked in Git.
- Each change is a versioned SQL file, applied in order.
- Pull-request review on schema changes.
- Deployment is still manual — someone runs the tool against an environment.

## Level 3 — Streamlined

**Level 3 is when database changes deploy through a CI/CD pipeline**. Rollback and environment promotion built in. Migration tools apply changes deterministically without a human running them.

- CI/CD applies changes to dev, staging, prod.
- [Liquibase](/blog/bytebase-vs-liquibase/) or [Flyway](/blog/bytebase-vs-flyway/) manage the apply-and-track loop.
- Failed deployments roll back automatically (within SQL's limits).
- Gap: ad-hoc work — emergency fixes, transient access grants — still bypasses the pipeline.

## Level 4 — Integrated

**Level 4 is when planned changes and ad-hoc tasks live in the same platform**, with shared approval, audit, and access models. L2 and L3 handle planned changes. Ad-hoc work — patching a row, granting a temporary credential, running a one-off `ANALYZE` — falls outside the version-controlled model. L4 closes the gap.

- Schema changes and ad-hoc operations flow through the same pipeline.
- One-off access grants follow the same approval flow as schema changes.
- Standing permissions sync from external identity providers (Okta, AD, LDAP).
- All human-to-database actions land in one searchable audit log.

<HintBlock type="info">

[Bytebase](/blog/database-as-code/) operates at Level 4. Schema changes, data changes, ad-hoc access, and permission grants flow through one workflow. One audit log captures all of it.

</HintBlock>

![change-query-secure-govern-database-all-in-one](/content/blog/_shared/db-scheme-lg.png)

## Level 5 — Fully Automated

**Level 5 is fully automated end-to-end**. Self-healing systems handle failures. No human handles routine operations — the database equivalent of a robotaxi. No production team operates here today.

- End-to-end automation from request to deployment to monitoring.
- Self-healing: automatic rollback when monitoring detects regressions.
- Compliance and security checks built into the pipeline.

Whether L5 should be a goal is contested. Most teams keep a human approving destructive operations.

## Where most teams sit

Across the database teams we work with: **L0 ~5%** (early-stage), **L1 ~40%** (most enterprise teams), **L2 ~25%**, **L3 ~20%** (CI/CD for schema, ad-hoc still outside), **L4 ~10%** (compliance-driven), **L5 0%**.

L1 is the most exposed cluster. Governance is in place — tickets, approvals, audit. Execution safety is not. A typo in production looks the same at L1 as at L0.

## FAQ

**What is database automation?**
Database automation manages database tasks — schema changes, deployments, access provisioning, audit — with minimal human intervention. The result: fewer errors, consistent policy, DBAs working on architecture instead of approving every change.

**What are the 6 levels of database automation?**
Six levels, named after the autonomous-driving framework. L0 No Automation. L1 Ticketing (approval, manual execution). L2 Version Controlled (schemas in Git). L3 Streamlined (CI/CD deployment). L4 Integrated (planned and ad-hoc tasks in one platform). L5 Fully Automated (end-to-end with self-healing).

**Is database CI/CD the same as database automation?**
Database CI/CD is one layer — Level 3, automated deployment of planned schema changes through a pipeline. Full automation also covers governance (L1), version control (L2), and ad-hoc work that doesn't fit a pipeline (L4). A team running Liquibase in GitHub Actions has database CI/CD. It is not yet at Level 4.

**What tools enable database automation?**
Jira or ServiceNow for L1 ticketing. Git plus migration files for L2. Liquibase or Flyway in CI/CD for L3. Platforms like Bytebase that combine schema change, ad-hoc access, and audit for L4. Most teams run a mix — Jira for governance, Flyway for apply. The gap between them is what L4 platforms close.

**How mature is database automation today?**
Most enterprise teams sit at Level 1 (~40%) or Level 2 (~25%). About 20% have reached Level 3 with CI/CD pipelines for schema changes. Roughly 10% have closed the ad-hoc gap at Level 4. Level 5 is not in production at any team we've worked with.

**What's the highest level of database automation?**
Level 5 — end-to-end automation with self-healing, no human handling routine operations. Theoretical highest, not deployed. No production team runs without human approval for destructive operations. Most explicitly choose not to. Level 4 is the highest seen in production.



As the engineering team grows and more database change operations are executed on a daily basis, we need to find a centralized way to coordinate and enforce the database change process. A quick approach is to rely on the existing in-house ITSM (IT service management) or a simple ticketing system. Among them, Jira is probably the most popular option.

## A Typical Jira Setup

1. Define a [custom Jira workflow](https://www.atlassian.com/software/jira/guides/workflows/overview#what-is-a-jira-workflow).
   You may define a dedicated status set for the database change process. e.g. `Created`, `Reviewing`, `Pending Rollout`, `Completed`.

1. Define a [custom Jira issue type](https://support.atlassian.com/jira-cloud-administration/docs/add-edit-and-delete-an-issue-type/)
   and some [custom fields](https://support.atlassian.com/jira-cloud-administration/docs/configure-issue-custom-fields/) such as `SQL`, `Database`, `Rollout Time`.

1. Create roles for the reviewers (normally DBA or the project owner) and requesters (normally the developer) respectively.

## Database Change Workflow

<HintBlock type="info">

The similar workflow can also be applied to other database tasks such as requesting query access and data export.

</HintBlock>

1. The developer creates a Jira issue to request the database change. She fills the issue with the `SQL`, `Database` info. The issue status is `Created`.

1. The DBA gets assigned to the issue according to the configured workflow. DBA reviews the SQL and leaves a comment under the issue. The issue status is `Reviewing`.

1. After several back-and-forth communications, the DBA approves the issue and changes the issue status to `Pending Rollout`.

1. The DBA pastes the SQL from the Jira ticket into their favorite SQL client and execute.

1. The DBA updates the issue status to `Completed`.

## Space for Improvement

With Jira, teams can now have a centralized place to review and coordinate the database changes. However, there is still plenty of space for improvement.

### Disconnected Review and Rollout process

- The DBA needs to manually paste the SQL to a different place to execute it. The DBA could paste the wrong SQL or execute against the wrong
  database (**the infamous mistake of pointing to the production database incorrectly**).

- Change histories are obscure. It's hard to track why, when, and how a database change happens.

### Lack of Customization for the Database Domain

Database changes can get quite complex:

- Propagating the changes across different environments.

- Batch changing multiple databases having the same schema (typical for multi-tenant/multi-region setups).

- Enforcing automatic SQL lint checks.

- Streamlining rollbacks.

It's challenging to force a general issue ticketing system to handle the specialized database tasks.

## Why Bytebase

Many customers come to [Bytebase](/) from Jira because of the aforementioned challenges. Similar to Jira,
Bytebase has the concepts of `Project`, `Issue`. Additionally, Bytebase defines some database domain-specific concepts as first-class citizens, such as `Database Instance`, `Database`, `Environment`. Bytebase provides an integrated
experience to plan, review, and deploy database changes.

![Issue detail interface](/content/blog/use-jira-for-database-change/issue-detail.webp)



We have been working with PostgreSQL and other databases for a while. In the realm of database management, PostgreSQL stands out for its robustness and flexibility. However, as developers navigate the complexities of modern application development, there are additional functionalities that could streamline their workflows. Here are the features I wish PostgreSQL had to make developers' lives easier:

## Versioned Schema

The PG catalog only stores the current schema. Schema migration tools usually need to create an external table to store the schema migration history. A built-in versioned schema will be beneficial:

1. Standardize the format. e.g. The version string, the status indicating whether the schema change is in progress.
2. Consistency. When schema migration history is stored externally, it's hard to guarantee the consistency between the migration history and the actual schema.
3. Rollback. If a new schema change introduces issues, versioning allows for safer rollbacks to previous stable states, minimizing downtime and impact on users.
4. Process enforcement. With a versioned schema and the migration history, it's easier to enforce that only a single schema migration can run on a database at any point in time.

## Online Schema Migration

PostgreSQL has been improving this area over the years, but there are still cases where altering the schema would block the database. [pg-osc](https://github.com/shayonj/pg-osc), [reshape](https://github.com/fabianlindfors/reshape) are built to tackle this. Ideally, PostgreSQL can encapsulate the long schema migration process:

- Temp tables created as part of the migration are internal tables. Thus it won't pollute the user space.
- Postgres exposes a migration progress percentage.

## State-based Migration (Declarative)

The typical way to do schema migration is to compose a list of `ALTER TABLE` statements. This becomes hard to track the latest schema state as the migration accumulates. It's more intuitive for the developers to specify the desired state. Ideally, PostgreSQL could allow developers to specify the desired `CREATE TABLE` schema, the engine then reconcile it with the latest schema, figure out the diff, and plan the migration path internally.

## Branching

During development, it's desirable to have a high-fidelity testing environment as close as the prod environment. The challenge is to fork the production database quickly enough (for compliance, it also needs to sanitize the sensitive data). What if PostgreSQL could have the instant git-like branching?

## Archived Table

To prevent deleting data by mistake, we invent soft-delete pattern by having a `is_deleted` column. However, this brings extra complexities around foreign key, unique index enforcement. Ideally, PostgreSQL could allow users to configure an archived table. The removed data is moved to the archived table first and purged after a configured retention period. This simplifies application logic and data compliance work.

## Label

PostgreSQL allows adding [SECURITY LABEL](https://www.postgresql.org/docs/current/sql-security-label.html) to the objects. I wish it could be extended to a more generic label system where users can attach arbitrary KV pairs. This would be useful in data dictionary, reporting, and orchestrating developer workflow. e.g.

- Find all tables/databases owned by a particular application.
- Require additional review when changing tables matching a certain label.

## Git Integration

Snowflake added this one in the [2023 summit](https://medium.com/snowflake/streamlining-devops-with-snowflake-and-git-integration-fc0b76a40a76):

![snowflake-git](/content/blog/features-i-wish-postgres-had/snowflake-git.webp)

This allows developers to keep the stored procedures, user-defined functions, and operational scripts in the same place as the application code. Thus they will adopt the same version control best practices.

Similar to how Foreign Data Wrapper (FDW) is implemented, the core PostgreSQL could provide the underlying infrastructure, and the specific VCS integration can be implemented as an extension.

## Summary

As to the database development workflow, Git is always the source of inspiration. Git is invented to
manage the stateless code, the hard part is to adapt Git to manage the stateful database. Companies
have already been pushing the frontiers:

- [Neon](https://neon.tech/) rebuilds the Postgres engine to enable serverless and instant branching.
- [Xata](https://xata.io/) offers serverless, branching, as well as zero-downtime schema migration.
- [Snaplet](https://snaplet.dev/) for seeding and sanitization.
- [Supabase](https://supabase.com/) for an entire application platform around Postgres.
- [Bytebase](https://bytebase.com/) for unifying all human-to-postgres operations including schema migration, ad-hoc change, database access control, and dynamic masking.

What's your most desired PostgreSQL feature?



GitOps is a modern approach to manage infrastructure that emphasizes automation, collaboration, and continuous delivery. It’s based on the idea of using Git as the single source of truth for configuration and code. With GitOps, all changes to infrastructure are made through pull requests, which are reviewed and approved by other team members before being merged into the main branch.

In this post, we are reviewing several open-source GitOps tools:

- [Terraform](#terraform)
- [Pulumi](#pulumi)
- [ArgoCD](#argocd)
- [Bruno](#bruno)
- [Bytebase](#bytebase)
- [OPA](#opa)
- [mdx](#mdx)

[![star-history](/content/blog/top-open-source-gitops-tools/star.webp)](https://www.star-history.com/#hashicorp/terraform&pulumi/pulumi&argoproj/argo-cd&usebruno/bruno&open-policy-agent/opa&mdx-js/mdx&bytebase/bytebase&Date)

## Terraform

[Terraform](https://github.com/hashicorp/terraform) is an open-source infrastructure as code tool (IaC) that lets you build, change, and version infrastructure safely and efficiently. This includes low-level components like compute instances, storage, and networking; and high-level components like DNS entries and SaaS features.

Terraform uses HashiCorp Configuration Language (HCL) and also supports JSON for writing configurations.
![terraform](/content/blog/top-open-source-gitops-tools/terraform.webp)

To enable GitOps, create a Git repo with Terraform configs, define infrastructure in Terraform, and manage updates via a pipeline and pull requests.

![terraform-gitops](/content/blog/top-open-source-gitops-tools/terraform-gitops.webp)

## Pulumi

[Pulumi](https://github.com/pulumi/pulumi) is an open-source infrastructure as code tool that allows you to create, deploy, and manage cloud infrastructure using your favorite language. Unlike Terraform, Pulumi uses real programming languages like Python, JavaScript, and Go to define infrastructure.

![pulumi](/content/blog/top-open-source-gitops-tools/pulumi.webp)

Similar to Terraform, Pulumi can be used to enable GitOps by creating a Git repo with Pulumi configs, defining infrastructure in Pulumi, and managing updates via a pipeline and pull requests.

![pulumi-gitops](/content/blog/top-open-source-gitops-tools/pulumi-gitops.webp)

## ArgoCD

[ArgoCD](https://github.com/argoproj/argo-cd) is a declarative, GitOps continuous delivery tool for Kubernetes.

![argocd](/content/blog/top-open-source-gitops-tools/argocd.webp)

Argo CD follows the GitOps pattern of using Git repositories as the source of truth for defining the desired application state. Kubernetes manifests can be specified in several ways such as kustomize applications, helm charts and jsonnet files.

Argo CD automates the deployment of the desired application states in the specified target environments. Application deployments can track updates to branches, tags, or pinned to a specific version of manifests at a Git commit.

![argocd-diff](/content/blog/top-open-source-gitops-tools/argocd-diff.webp)

## Bruno

[Bruno](https://github.com/usebruno/bruno) is a Fast and Git-Friendly open-source API client, aimed at revolutionizing the status quo represented by Postman, Insomnia and similar tools out there.

![bruno](/content/blog/top-open-source-gitops-tools/bruno.webp)

Bruno stores your collections directly in a folder on your filesystem with a plain text markup language, Bru, to save information about API requests.

Regarding GitOps, you can use git or any version control of your choice to collaborate over your API collections.

![bruno-gitops](/content/blog/top-open-source-gitops-tools/bruno-gitops.webp)

## OPA

[OPA](https://github.com/open-policy-agent/opa) (Open Policy Agent) is an open-source policy engine designed to enforce policies across your stack. While OPA is not a GitOps tool itself, it can complement GitOps workflows by providing policy enforcement and compliance checks.

![opa](/content/blog/top-open-source-gitops-tools/opa.webp)

In the context of GitOps, OPA can be integrated into your CI/CD pipelines or Kubernetes admission controllers to validate changes to your infrastructure and applications. By enforcing policies defined in code, OPA ensures that all changes comply with your organization's standards before they are applied, enhancing the security and reliability of your GitOps processes.

## MDX

[MDX](https://github.com/mdx-js/mdx) is a tool that allows you to write JSX in Markdown documents, enabling the creation of interactive and dynamic content using React components within your Markdown files.

![mdx](/content/blog/top-open-source-gitops-tools/mdx.webp)

While MDX is not a traditional GitOps tool, it can complement GitOps workflows by enabling version-controlled documentation. This ensures that your documentation evolves alongside your code and infrastructure, maintaining alignment with the latest changes.

## Bytebase

[Bytebase](https://github.com/bytebase/bytebase) is an all-in-one database DevSecOps and CI/CD solution. It's like GitHub/GitLab that provides a GUI workspace for developers and DBAs to collaborate on database changes.

![bb](/content/blog/top-open-source-gitops-tools/bb.webp)

Besides its intuitive UI workflow, Bytebase also supports a GitOps workflow for managing database changes. This feature allows for initiating database issues through pull requests. Furthermore, Bytebase provides SQL review, custom approval workflows, and rollout policies, enabling database changes to be managed in an advanced GitOps manner.

![bb-rollout](/content/blog/top-open-source-gitops-tools/bb-rollout.webp)

## Summary

To summarize, these open-source GitOps tools offer a range of options for managing infrastructure and application deployments. They adhere to the GitOps principles, automating the deployment process to achieve the desired states in specified target environments.



Once upon a time, a developer named John was modifying the name column in a large table from `VARCHAR(20)` to `VARCHAR(512)`. This change was intended to accommodate more diversity in name lengths, a request that had come down from the product team as they expanded into new, international markets. The exact SQL is:

```sql
ALTER TABLE person MODIFY name VARCHAR(512);
```

Bob, the Database Administrator (DBA), reviewed John's migration script. On the surface, it seemed like a straightforward change, one that he had seen and approved many times in his career. Bob gave his blessing to the change.

With Bob's approval, John executed the migration. As soon as the migration was deployed, alarms blared throughout the office.

The root cause is subtle. Even MySQL 8.0 has increased the online DDL coverage, this particular statement is still not covered. Because the statement enlarges the byte to encode the size value from 1 to 2 as described in the [official doc](https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html).

![mysql-extend-varchar](/content/blog/schema-migration-outage-fault/mysql-extend-varchar.webp)

Thus all other transactions were blocked while waiting for this DDL to finish. And for large tables, that would take hours.

**Though the industry is advocating the [blameless culture](https://sre.google/sre-book/postmortem-culture/), someone needs to be accountable. Otherwise, no one will own the initiative to fix the process and the chances are it will happen again.**

Is this the author, John’s fault? Maybe. However, it’s a bit more ask for an average developer to know the execution plan of a particular statement from a particular database at a particular version.

Is this the reviewer, Bob’s fault? Plausible. Since Bob has more knowledge and was hired exactly for catching this type of error. However, if Bob takes the bullet, there will be less incentive for the developers to improve their database knowledge.

The good thing is, that such dilemmas have become less nowadays:

1. Companies are moving more DB responsibilities to the developers. There will still be a DB person or a platform team taking care of the DB infrastructure, but the day-to-day DB development tasks are managed by the developer team entirely.
1. Companies may use an external DBA consulting service like [Vettabase](https://vettabase.com/), [Percona](https://www.percona.com/), [Enterprise DB](https://www.enterprisedb.com/) for expert advice.
1. Companies may adopt database development tools like Bytebase to improve the collaboration between the developers and the DB team.

Welcome to the era of Database DevOps.



I first published this post in February 2024, when the `Modern Snowflake Stack` was a constellation of independent vendors, each owning one layer around Snowflake. Two years later, half of them have merged, been acquired, or repositioned around AI agents. Time for a refresh.

![_](/content/blog/modern-snowflake-stack/semantic-layer-google-trend.webp)

If you want the refresh in one chart, this is it: Google Trends for `semantic layer`, flat for four years, then a >5,000% breakout once the agents arrived. The layer that did not exist in the 2024 version is now the hottest thing in the stack. We will get there.

Snowflake played the pivotal role in the `Modern Data Stack` era, so this post walks the tools built around it, layer by layer, and notes what changed since 2024.

## Data Ingestion - Fivetran

![_](/content/blog/modern-snowflake-stack/fivetran.webp)

[Fivetran](https://www.fivetran.com/) automates extracting and loading data into the warehouse through a large library of pre-built connectors. The Salesforce to Snowflake connector remains its flagship.

It is also where the biggest story of this refresh begins. In May 2025 Fivetran [acquired Census](https://www.fivetran.com/press/fivetran-signs-agreement-to-acquire-census-delivering-the-first-end-to-end-data-movement-platform-for-the-ai-era), the reverse-ETL leader. In October 2025 it announced a merger with dbt Labs, which [closed on June 1, 2026](https://www.fivetran.com/press/fivetran-dbt-labs-complete-merger-to-create-the-data-infrastructure-for-trusted-ai-agents) at nearly $600M combined annual revenue. Three boxes from my 2024 diagram now share one cap table.

Meanwhile Snowflake built its own ingestion: [Openflow](https://www.snowflake.com/en/news/press-releases/snowflake-openflow-unlocks-full-data-interoperability-accelerating-data-movement-for-ai-innovation/), launched at Summit 2025 on top of Apache NiFi (via the Datavolo acquisition). Native, event-driven, hundreds of connectors. Fivetran still wins on breadth and polish, but the moat is being circled.

## Data Transformation - dbt

![_](/content/blog/modern-snowflake-stack/dbt.webp)

[dbt (data build tool)](https://www.getdbt.com/) turns warehouse transformations into code: SQL models that are version-controlled, tested, and deployed. It remains the de facto standard for the "T" in ELT, and Snowflake remains its favorite execution engine.

Two changes. dbt Labs rewrote the engine in Rust (Fusion, built from the SDF acquisition) and open sourced its runtime as dbt Core v2.0 after the merger. And Snowflake made dbt native: [dbt Projects on Snowflake](https://www.snowflake.com/en/blog/dbt-projects-generally-available/) went GA in January 2026, running dbt entirely inside Snowsight. No dbt Cloud subscription, no self-hosted runner, no external orchestrator.

When your ingestion vendor owns your transformation tool, and your warehouse runs it natively, the boundary lines in any stack diagram start to look negotiable.

## Semantic Layer - Suddenly, Everyone

This layer did not exist in the 2024 version, and that is the point. The semantic layer is an old idea (BusinessObjects universes, OLAP cubes, LookML) that kept failing to become its own layer, because dashboards tolerate ambiguity: a human eyeballing a chart absorbs definitional drift. AI agents do not. Text-to-SQL against raw schemas produces plausible SQL; against a curated semantic model it produces governed SQL that a human approved.

The momentum is measurable: on Google Trends, the term that named the whole era is now a flat line under the layer it never bothered to include, average interest 14 versus 3 over five years.

![_](/content/blog/modern-snowflake-stack/semantic-layer-vs-modern-data-stack-trend.webp)

So everyone built one. Snowflake shipped [semantic views](https://docs.snowflake.com/en/user-guide/views-semantic/overview) that Cortex Analyst, CoWork, and CoCo all read from. Databricks answered with Unity Catalog [metric views](https://www.databricks.com/blog/redefining-semantics-data-layer-future-bi-and-ai), GA in April 2026 and open sourced into Apache Spark. dbt has owned MetricFlow since 2023, so the merged Fivetran + dbt owns one too. The independents ([Cube](https://cube.dev/), AtScale, Honeydew) repositioned as the neutral option, queried by agents over MCP.

The momentum peaked in an unlikely place: a standards body. [Open Semantic Interchange](https://www.snowflake.com/en/news/press-releases/snowflake-salesforce-dbt-labs-and-more-revolutionize-data-readiness-for-ai-with-open-semantic-interchange-initiative/) launched in September 2025, led by Snowflake and Salesforce, and published a vendor-neutral YAML spec in January 2026 with 40+ partners. When Snowflake, Databricks, and Salesforce co-sign a spec, you know where the choke point is: whoever owns the semantic layer owns the control plane for AI analytics. OSI makes definitions portable. Where they live is still the fight.

## Data Security - Immuta

![_](/content/blog/modern-snowflake-stack/immuta.webp)

[Immuta](https://www.immuta.com/) manages access control, masking, and privacy compliance at scale, for organizations handling sensitive data under GDPR, CCPA, HIPAA and friends.

Immuta is one of the survivors: still independent, still valued around $1B. But Snowflake's built-in governance grew into [Horizon Catalog](https://www.snowflake.com/en/product/features/horizon/), covering the baseline access control, masking, and discovery that used to justify a third-party purchase. Immuta responded by climbing up the stack: at Summit 2026 it launched [agentic data access](https://www.immuta.com/news/immuta-launches-new-agentic-data-access-capabilities-on-snowflake-ai-data-cloud/), zero-standing-privilege access for AI agents with a dual-identity audit trail. The pattern repeats across this list: when Snowflake absorbs your core feature, you go govern the agents instead.

## Data Catalog - Atlan

![_](/content/blog/modern-snowflake-stack/atlan.webp)

[Atlan](https://atlan.com/) is a data catalog and collaborative workspace for discovery, governance, and metadata. It had a good two years: a Leader in both the Gartner Magic Quadrant for Data & Analytics Governance (2026) and the Forrester Wave for Data Governance. Its Snowflake story evolved from "built on top of Snowflake's features" to "the cross-system layer above Horizon": Horizon governs what lives inside Snowflake, Atlan stitches lineage and policy across everything else. A sensible division of labor, as long as Snowflake stays on its side of the line.

## Data Monitoring - Bigeye

![_](/content/blog/modern-snowflake-stack/bigeye.webp)

[Bigeye](https://www.bigeye.com/) started as a data observability platform: data quality monitoring, anomaly detection, lineage. That is now the smaller half of the company. Bigeye rebranded around an "AI Trust Platform" and in June 2026 launched Agent Trust Hub, mapping AI agent activity to data quality, classification, lineage, and cost signals. Same telemetry, new customer: the thing consuming your data is no longer just a dashboard.

Snowflake made its own observability move in January 2026: [acquiring Observe](https://www.snowflake.com/en/news/press-releases/snowflake-announces-intent-to-acquire-observe-to-deliver-ai-powered-observability-at-enterprise-scale/) for roughly $1B, the largest acquisition in its history. To be fair, Observe is infrastructure telemetry (logs, traces, an AI SRE) rather than data quality, so Bigeye is not directly displaced. But Snowflake clearly wants the observability workload too.

## Data Activation - Census / Hightouch

In 2024 I wrote that Census and Hightouch were neck-to-neck in reverse-ETL and that it was better to leave the judgement to the audience. The market delivered the judgement for us. Census sold to Fivetran in May 2025 and now lives on as Fivetran's activation layer. Hightouch stayed independent, raised at a $1.2B valuation, and repositioned as a Composable CDP with [AI Decisioning](https://hightouch.com/platform/ai-decisioning): instead of syncing segments that humans define, an AI decides which message goes to which customer.

Two companies that once shipped mirror-image comparison pages ended up in different businesses entirely. Reverse-ETL turned out to be a feature, not a company. Census accepted that; Hightouch out-ran it.

The 2024 version gave Segment its own CDP section. Its update is corporate rather than technical: activist investors pushed Twilio to divest it; after an operational review Twilio [decided to keep it](https://www.twilio.com/en-us/press/releases/twilio-concludes-operational-review-of-segment). Meanwhile the composable-CDP camp led by Hightouch keeps arguing your warehouse should be the CDP, and that argument gets easier every year. So Segment loses the standalone section, and this stack gets a little more Snowflake-shaped.

## CI/CD - Bytebase

After all, Snowflake is a database system, and the pain point for any database is schema migration. Everything above is DataOps; schema migration is CI/CD. Snowflake open sourced [schemachange](https://github.com/Snowflake-Labs/schemachange), a python CLI in the spirit of [flyway](https://github.com/flyway/flyway), and it is still maintained. The bigger native move is [DCM Projects](https://docs.snowflake.com/en/user-guide/dcm-projects/dcm-projects-overview) (public preview since March 2026): declare the desired state of your Snowflake objects, and Snowflake plans and applies the diff, terraform-style, without terraform state drift.

[Bytebase](/) approaches the same problem from the review side. It provides a GUI collaborative workspace with review workflow and version control for Snowflake schema migrations and ad-hoc changes, like what GitHub does for code management.

![_](/content/blog/modern-snowflake-stack/snowflake-issue.webp)

It also provides native GitOps integration with all mainstream VCSs to manage the change scripts in the repository.

![_](/content/blog/modern-snowflake-stack/vscode-create-table.webp)

The practical difference: schemachange and DCM Projects manage Snowflake. Bytebase manages Snowflake next to everything else, because Snowflake is rarely your only database. The same review workflow, approval policy, and audit trail apply to the PostgreSQL and MySQL fleet feeding the warehouse. If your change process ends at the warehouse boundary, you have two change processes.

## Data Analytics - Hex

![_](/content/blog/modern-snowflake-stack/hex.webp)

[Hex](https://hex.tech/) is an AI analytics platform built around notebooks: SQL, Python, and no-code in one workspace, published as interactive data apps and dashboards. Since 2024 it went all-in on agents: a Notebook Agent that writes queries and builds charts, Threads reachable from Slack, semantic models to keep the answers governed.

Hex was not in the 2024 version either; it earns the slot because of who keeps funding it. Snowflake Ventures invested, [increased its stake](https://www.snowflake.com/en/blog/snowflake-ventures-increases-investment-in-hex/), then joined the [$70M Series C](https://hex.tech/blog/series-c/) in May 2025. It also inherited much of Mode's audience after ThoughtSpot acquired Mode. Not Snowflake-exclusive (it speaks BigQuery, Databricks, and Redshift too), but the closest thing to an ecosystem-blessed analytics front end for Snowflake.

## The BI prediction, graded

In the 2024 version, this section was called "What are we missing?" and noted the elephant in the room: there was no outstanding BI tool built specifically for Snowflake. I wrote: "Maybe the industry is just waiting for Snowflake to announce its own BI solution, not a far sight from Snowsight anyway."

Grading honestly: half right. Snowflake did ship its own answer: Cortex Analyst (natural language to SQL against a governed semantic layer), then Snowflake Intelligence, renamed CoWork at Summit 2026: a conversational agent that answers questions, publishes live RBAC-scoped dashboards, and generates deliverables on Snowflake data. But calling it a BI solution is a stretch. No drag-and-drop authoring, no pixel-perfect layout, Snowflake-only. Teams still keep Tableau or Looker for the hand-crafted dashboards, so the elephant is still in the room. What Snowflake shipped is a different bet: you ask an agent instead of opening a dashboard. Whether that bet retires the BI license is a prediction for the next refresh.

## Summary

The 2024 summary opened with a chart of `Modern Data Stack` picking up; this refresh opened with `semantic layer` breaking out. The torch has passed. Jim Barksdale said there are only two ways to make money in business: bundling and unbundling. The Modern Data Stack era was the great unbundling: one vendor per layer, composed via the warehouse. Now comes the re-bundling. Fivetran, dbt, and Census merged into one company. Snowflake absorbed ingestion (Datavolo becoming Openflow), transformation (native dbt Projects), observability (Observe), BI (CoWork), and even OLTP: it bought Crunchy Data to ship [Snowflake Postgres](https://www.snowflake.com/en/blog/snowflake-postgres-enterprise-ai-database/) weeks after Databricks [paid ~$1B for Neon](https://www.databricks.com/company/newsroom/press-releases/databricks-agrees-acquire-neon-help-developers-deliver-ai-systems). When both warehouse giants buy a Postgres company in the same season, that tells you where the puck is heading ([and Databricks still disagrees with Snowflake on everything else](https://www.databricks.com/databricks-vs-snowflake)).

The independents that remain (Atlan, Immuta, Bigeye, Hightouch) all made the same move: reposition one level up, from governing data to governing the AI agents that consume it. The stack consolidated; the pendulum will swing back. See you in 2028!



<HintBlock type="info">

This post is maintained by Bytebase, an open-source database governance platform. We update the post periodically.

</HintBlock>

MySQL is the most popular open-source relational database management system (RDBMS), and MySQL schema migration remains notoriously painful. Several open-source migration tools have emerged with different capabilities and workflows. All of the tools below are actively maintained as of 2026:

- [Skeema](https://www.skeema.io/)
- [Liquibase](https://www.liquibase.com/)
- [Flyway](https://flywaydb.org/)
- [Bytebase](https://www.bytebase.com/)

One adjacent category is deliberately excluded: **online schema change** tools like gh-ost and pt-online-schema-change, which rebuild large tables without blocking writes. They complement rather than replace the migration tools below, and we compare them in depth in [gh-ost vs pt-online-schema-change](/blog/gh-ost-vs-pt-online-schema-change/).

## Skeema

[Skeema](https://www.skeema.io/) is a schema management system for MySQL and MariaDB. It enables management of table definitions and schema changes in a declarative fashion using pure SQL.

![skeema](/content/blog/top-open-source-mysql-migration-tools/skeema.webp)

Skeema supports a pull-request-based workflow for schema change submission, review, and execution. This permits your team to manage schema changes the same way as you manage code changes.

Skeema has a companion SaaS tool, Skeema Cloud Linter, that provides automatic linting of schema change commits and pull requests.

GitHub uses both Skeema and gh-ost to [automate its MySQL schema migration process](https://github.blog/2020-02-14-automating-mysql-schema-migrations-with-github-actions-and-more/).

## Liquibase

[Liquibase](https://github.com/liquibase/liquibase) is arguably the most well-known product in this segment. It's CLI-based and written in Java.

In Liquibase, the schema migrations are organized as `Changeset` and `Changelog`. Probably due to its age and root in Java, the most commonly used form is XML (YAML and JSON support have been added later):

![_](/content/blog/_shared/liquibase-xml.webp)

Plain SQL is also supported with proper annotation:

![_](/content/blog/_shared/liquibase-sql.webp)

## Flyway

[Flyway](https://github.com/flyway/flyway) is another open source project with a long history and a large customer base. Its core product includes the CLI and a Java library.

Flyway has been acquired by Redgate, while it still retains a developer-oriented approach. This can be felt from its website.

![_](/content/blog/_shared/flyway-migration.webp)

Liquibase and Flyway are closely matched in their offerings. The key distinction between them is their target audiences: Liquibase is oriented towards serving enterprise clients, whereas Flyway presents itself as more developer-friendly and approachable.

## Bytebase

[Bytebase](https://github.com/bytebase/bytebase) is an all-in-one database DevOps and CI/CD solution. It's like GitHub/GitLab that provides a GUI workspace for developers and DBAs to collaborate on database changes. It's written in Go and TypeScript.

![issue-detail](/content/blog/top-open-source-postgres-migration-tools/issue-detail.webp)

It also provides configurable SQL lint rules to detect SQL anti-patterns.

![sql-review](/content/blog/top-open-source-postgres-migration-tools/sql-review.webp)

For MySQL, it also provides a GUI wrapper around gh-ost for online schema migration.

![bb-issue-ghost-config](/content/blog/top-open-source-mysql-migration-tools/bb-issue-ghost-config.webp)

Apart from taking care of database change management, Bytebase also provides a SQL Editor with data access control, dynamic data masking and audit logs to control the query path.

![sql-editor](/content/blog/top-open-source-postgres-migration-tools/sql-editor.webp)

## Summary

| Name                                                | Interface | Language        | MySQL Only          | Highlight                               |
| --------------------------------------------------- | --------- | --------------- | ------------------- | --------------------------------------- |
| [Skeema](https://github.com/skeema/skeema)          | CLI       | Go              | N (MySQL + MariaDB) | Declarative pure-SQL schema management. |
| [Liquibase](https://github.com/liquibase/liquibase) | CLI       | Java            | N                   | Long-standing.                          |
| [Flyway](https://github.com/flyway/flyway)          | CLI       | Java            | N                   | Developer-friendly.                     |
| [Bytebase](https://github.com/bytebase/bytebase)    | GUI       | Go + TypeScript | N                   | All in one for team collaboration.      |

## References

- [How to install local MySQL on Mac, Ubuntu, CentOS, Windows](/reference/mysql/how-to/how-to-install-mysql-on-mac-ubuntu-centos-windows/)


The
Bytebase Blog

Explore the standard for database governance

Solutions & Platform

Resources

Change Management

Access & Security

AI & Agents

Comparisons

Company

Legal

The Bytebase Blog

Explore the standard for database governance

The
Bytebase Blog