Worth noting that this approach uses the external tool technique, which makes a copy of the table with triggers.
MySQL and MariaDB both support native online DDL, which makes alter statements non-blocking and zero downtime in most cases, in even in-place (no whole table data copy) in some cases.
pt-online-schema-change is still useful when you want control on when the tables are swapped over.
Historically, native online DDL in MySQL 5.6+ / MariaDB 10+ isn't replication-friendly -- despite being non-blocking on the primary, it blocks the replication stream application on replicas, which makes it basically unusable at scale. (This is inherently a trade-off of MySQL/MariaDB using logical replication, instead of physical replication of the tx log / WAL.)
The newer INSTANT algo in MySQL 8 and MariaDB 10.3+ solves this, but it is only usable for a limited subset of alter operations, such as adding a new column. That's one of the most common ALTER cases, so this feature is quite nice, but it certainly doesn't solve everything.
For this reason, external tools such as pt-online-schema-change are still pretty essential for MySQL/MariaDB deployments of any non-trivial size.
MariaDB 10.8, which is still pre-GA, adds a clever solution to the replication problem: https://jira.mariadb.org/browse/MDEV-11675 . It will be interesting to see if there are any real-world operational drawbacks to this approach, and seeing if MySQL offers this soon as well.
MySQL and MariaDB both support native online DDL, which makes alter statements non-blocking and zero downtime in most cases, in even in-place (no whole table data copy) in some cases.
pt-online-schema-change is still useful when you want control on when the tables are swapped over.