MySQL solutions in PostgreSQL: Polar architecture for high performance

# Integrating MySQL Solutions into PostgreSQL: Architectural Innovations for High Performance

At the PG BootCamp 2026 conference, Alexey Kopytov (author of sysbench and former developer at MySQL AB/Percona) presented a talk on porting optimizations from the MySQL ecosystem to PostgreSQL. The key takeaway—leveraging proven solutions to boost PostgreSQL's fault tolerance and performance in high-load systems. Of particular interest is the implementation of compute-storage separation technology, adapted by the Tantor team based on Alibaba PolarDB.

The main advantage of this approach is maintaining full compatibility with PostgreSQL while significantly boosting throughput. Unlike sharding or distributed solutions (Citus, Greenplum), Tantor Polar architecture handles cross-shard queries without sacrificing ACID guarantees, which is critical for OLTP systems.

Classification of Architectural Solutions for DBMS

Alexey Kopytov proposed a clear classification of existing approaches to separating compute and storage nodes:

• Sharding and MPP systems (Greenplum, Citus): separation at the SQL parser level. Problem—lack of consistency at the single point in time level (xid/SCN)
• Distributed transactional DBMS (Spanner, YugabyteDB): transaction processing on storage nodes
• "LOG is DB" architectures (Amazon Aurora, Neon): primacy of the change log, WAL processing on storage
• Polar architecture (Tantor Polar): separation directly above the storage layer

The key distinction of the Polar approach is minimizing changes to the PostgreSQL core. All optimizations are implemented at the file system level (PolarFS), which enables:

• 100% compatibility with existing applications (including 1C)
• Avoiding invasive changes to PostgreSQL core
• Support for existing backup tools

Tantor Polar Architecture: Technical Implementation

The system is built on three key components:

• PolarFS—high-performance file system over RDMA/NVMe-oF
• RDMA network—for communication between compute and storage nodes
• Modified PostgreSQL—with minimal changes to the I/O subsystem

A standout feature is using Linux MD Cluster as the base layer for block devices. This solution delivers:

• Data access latencies comparable to local SSD (5-10 μs)
• Transparent scaling of compute nodes independent of storage
• Support for Active-Active mode on RW nodes

Importantly, PolarFS operates via the standard POSIX interface, eliminating the need for PostgreSQL core modifications. All changes are confined to the file system driver, greatly simplifying upstreaming and maintenance.

Comparison with Oracle RAC and Other Solutions

While conceptually similar to Oracle RAC, the differences are significant:

• Data transfer protocol: Polar uses NVMe-oF over RDMA, RAC uses a proprietary protocol
• Separation level: Polar separates at the file system level, RAC at the ASM level
• Open source: PolarFS will be released as open source, unlike ASM

RDMA implementation deserves special mention. Early attempts (in PostgresPro 10-11) required deep PostgreSQL core modifications. Tantor took a non-invasive approach via the file system driver, enabling:

• Elimination of asymmetric access latency issues
• Uniform performance across all compute nodes
• Preservation of the standard WAL handling mechanism

Key Takeaways

• Compatibility without compromises: Tantor Polar supports all PostgreSQL features, including complex JOINs and transactions
• RDMA performance: latencies on par with local SSD (5-10 μs) over the network
• Scalability: compute and storage scale independently
• Openness: PolarFS will be available under an open-source license
• Production readiness: the solution is already in use at XData Gen.3 with a 3 storage + N compute node configuration

Technical Implementation Details

Key architecture components:

// Example of RDMA integration into the I/O subsystem
static int polarfs_submit_io(struct io_request *req) {
    if (use_rdma) {
        return rdma_send(req->buffer, req->length);
    }
    return posix_write(req->fd, req->buffer, req->length);
}

Optimizations focus on three areas:

• Buffer management: metadata caching on compute nodes
• WAL handling: asynchronous RDMA sends with acknowledgments
• Lock manager: distributed implementation without a single point of failure

Special attention went to edge cases:

• Recovery after RDMA connection drops
• Handling asymmetric network latencies
• Guaranteeing atomicity of write operations

Benchmarks with PolarFS show:

• Throughput increases of 35-40% under high load
• 99th percentile latencies reduced by 2.3x
• Peak transactions per second up by 28%

Conclusion

Tantor's approach shows how porting solutions between DBMS ecosystems can yield major gains. The key to success—minimal invasiveness and a focus on compatibility. Polar architecture unlocks new scaling possibilities for PostgreSQL in scenarios that previously demanded radical app changes or a switch to NoSQL.

Notably, the implementation requires no specialized hardware—just RDMA and NVMe-oF network support. This makes it accessible to a wide range of organizations facing growing loads on existing PostgreSQL clusters.

— Editorial Team