The first query language for PostgreSQL, PL/pgSQL, is similar to Oracle's PL/SQL. PostgreSQL supports SQL:2003 PSM stored procedures as well as many other general purpose programming languages such as Perl (PL/Perl), Python (PL/Python), TCL (PL/Tcl), Java (PL/Java) and C (PL/C).

MySQL follows the SQL:2003 syntax for stored routines, which is also used by IBM's DB2.

—MySQL AB , MySQL 5.1 Reference Manual :: 18 Stored Procedures and Functions

Via the plugin interface MySQL supports external language stored procedures in Java, Perl, XML-RPC with more language plugins in the works.

Both PostgreSQL and MySQL support triggers. A PostgreSQL trigger can execute ANY user-defined function from any of its procedural languages, not just PL/pgsql.

MySQL triggers are activated by SQL statements only. They are not activated by changes in tables made by APIs that do not transmit SQL statements to the MySQL Server; in particular, they are not activated by updates made using the NDB API.

—MySQL AB , MySQL 5.1 Reference Manual :: 19 Triggers

MySQL triggers are also not activated by cascading updates and deletes even when caused by a SQL statement (this is against the standard), since those are a feature of the InnoDB engine rather than the database as a whole. In these cases, MySQL silently ignores the triggers without issuing a warning (i.e. in other dbms's you must be extra careful to not pop triggers accidentally, in MySQL you must be extra careful that many of your statements will not activate the triggers, such as cascades, etc.).

PostgreSQL also supports "rules," which allow operating on the query syntax tree, and can do some operations more simply that are traditionally done by triggers. However, the rule system is on the way out in favour of (more powerful) triggers.

Syntax for definition of triggers in PostgreSQL isn't as straightforward as in MySQL. PostgreSQL requires separate definition of a function with specific data type returned (this is the general behaviour of PostgreSQL = more strict vs MySQL = less strict. The syntax in itself is as straightforward but the implementation is stricter and much more powerful (any user function), thus a bit harder to learn). On the upside, PostgreSQL supports multiple actions per trigger using OR (e.g. BEFORE INSERT OR UPDATE).

MySQL does NOT support multiple triggers of the same type (i.e. maximum one ON UPDATE BEFORE and one ON UPDATE AFTER trigger) on the same table, whereas PostgreSQL does (If multiple triggers of the same kind are defined for the same event, they will be fired in alphabetical order by name. > from the manual).

PostgreSQL supports deferrable triggers that fire at transaction commit time (primarily useful for implementing deferred constraint checks). MySQL does NOT support deferrable triggers or deferrable constraint checking.

PostgreSQL, as of 9.0, supports triggers that fire only before or after updates on specific columns (i.e., BEFORE/AFTER UPDATE OF column_name[,...]), or when a user defined condition holds (WHEN condition). MySQL does not directly support either of these features, but they can be emulated in the user-defined trigger code.

PostgreSQL, as of 9.1, supports TRIGGERS on views, MySQL does not.

Replication is a database management system's ability to duplicate its stored data for the purposes of backup safety and is one way to prevent database downtime. PostgreSQL and MySQL both support replication:

PostgreSQL has built-in asynchronous replication as of 9.0, consisting of streaming replication and hot standby [7]. PostgreSQL streams the write-ahead log data which replays activity on the database guaranteeing identical results. MySQL's older form of statement based replication could introduce slave inconsistency when executing non-deterministic statements. MySQL now warns when using potentially unsafe statements, switching to a ROW image based log format.

There are several packages that also provide replication in PostgreSQL:

It is a common misconception that these "third-party packages" are somehow less well integrated. Slony, for example, was designed and built by Jan Wieck, a PostgreSQL core team member, and has a number of other members of the PostgreSQL community involved in its ongoing design and maintenance. However, Slony is considerably slower and uses more resources than built-in replication, as it uses SQL and triggers rather than binary log shipping to replicate the data across servers. That may make it less suitable for larger cluster deployments with high performance demands.