NDB is a high performance, highly available, (mostly) in-memory storage engine. Non-indexed attributes may be stored on disk. Data and logs are automatically flushed to disk periodically to mitigate data loss in the event of a cluster failure. NDB is used heavily in Telecommunications applications where uptime and real time performance is critical. NDB transparently organizes records into fragments which are distributed evenly to all nodes in the cluster. NDB uses synchronous replication internally to ensure records are committed to at all nodes within a logical node group before returning a COMMIT. This two phase commit gives NDB the ability to support sub-second failover. Further to this NDB also supports automatic node recovery. NDB supports the online introduction of additional nodes to the cluster without impacting availability of the application.
Significant Limitation: The distributed nature of the tables makes NDB perform poorly for complex JOIN operation as compared to traditional storage engines. This has been resolved in version ndb-7.2.1 and later with Adaptive Query Localization (distributed pushed-down join, formerly SPJ)
PostgreSQL: PostgreSQL has no comparable solution.

MySQL supports on-the-fly compression since version 5.0 with the ARCHIVE storage engine. Archive is a write-once, read-many storage engine, designed for historical data. It compresses data up to 90%. It does not support indexes. In version 5.1 Archive engine can be used with partitioning.

Aria is a fully ACID compliant, storage engine being incrementally developed by Monty Widenius and a team of other former MySQL developers. The incremental development model means that the full ACID feature set is gradually evolving.

Historically MySQL has focused more on scale-out than scaleup and PostgreSQL is often considered to scale better with large numbers of cores or uncommonly high concurrency levels.

With the increased availability of multi-core systems MySQL has been working to improve this, through both new development (5.5 and 5.6) and the incremental development of 5.0 via bug fixes that remove bottlenecks. The continuous incremental improvements without major or minor version number changes makes it vital to compare with recent builds of the server, not just looking at the main version number. A partial list of versions with significant performance improvements is 5.0.30, 5.0.54 and 5.0.58 and any benchmark result older than those versions should be considered to be particular to older installations, especially in the areas of concurrency and scalability.

Along with MySQL's internal work on concurrency many patches from Google and Percona hold promise and some have been incorporated into the standard MySQL server in version 5.4.

PostgreSQL supports a full fledged asynchronous API for use by client applications. It is reported to increase performance by up to 40% in some cases. MySQL lacks Async support, though some drivers have been created to attempt to overcome this deficiency (perl ruby).

Transactional databases which implement

Speed comparisons tend to depend on specific workloads and be used long after the versions involved are out of date, for example, tweakers.net and jamonation tests that precede many improvements that were implemented in MySQL 5.0 and the .

It's still true that in some benchmarks PostgreSQL may scale better with large numbers of cores at high concurrency levels. Equally, there are workloads where the same is true for MySQL, so the usual advice to test your own application continues to apply. PostgreSQL excels at workloads with a significant write workload[citation needed].

A new benchmark for MySQL 5.0.51 and MySQL 5.1.30 with InnoDB 1.0.3 (MySQL 5.4 contains the patches from InnoDB 1.0.3) compared with PostgreSQL 8.3.7 suggests that MySQL and PostgreSQL are almost equal in terms of scalability, by at least one standard of measure.

While benchmarks can be an indicator of performance, MySQL performance in many subquery / join statements is behind PostgreSQL due to the inferior Query Optimizer (a much wider benchmark would show PostgreSQL as a clear winner in this case).[citation needed]. Recent enhancements to the MySQL optimizer provide large gains in the performance of subquery / join statements.

ACID stands for Atomicity, Consistency, Isolation and Durability. This model is used to judge data integrity across database management systems. Most database systems achieve ACID compliance by using transactions AND enforcing triggers/ foreign keys (it's forgetting about this part that prevents consistency, as in InnoDB).

PostgreSQL is fully ACID compliant.