In the world of database management, performance is often a critical factor when choosing a procedural language. If you've ever wondered how PL.NET measures up in terms of performance within PostgreSQL, we've got the answers. In this post, we delve into our comprehensive performance testing and what sets pldotnet apart from the competition.
First and foremost, we believe in transparency and accountability. If you're interested in the nitty-gritty details, you can find all our performance data and tests in the PL.NET white paper, available for download. We encourage you to run these tests yourself to witness the results firsthand.
Our approach to performance testing was thorough. We didn't cherry-pick scenarios where we knew PL.NET would shine. Instead, we aimed for a representative sampling of various database operations across different PostgreSQL procedural languages, including C#, F#, pl/pgsql (the native one), Perl, Python, Lua, R, Java, and more.
Our motivation was clear: to identify any potential issues and ensure that we're building top-notch software. If our performance lagged significantly behind other languages, it would be a red flag, prompting us to reevaluate and optimize our code.
So, what did we discover when we ran these performance benchmarks? The results were nothing short of impressive. PL.NET emerged as an incredibly fast performer, nearly on par with pl/pgsql, the internal stored procedural language native to PostgreSQL.
Pl/pgsql has the advantage of operating natively within the database, leveraging PostgreSQL data types directly without the need to shuttle data between environments. Its SQL-like structure aligns seamlessly with the database's infrastructure. Yet, despite these advantages, pl/pgsql only holds a slight edge over PL.NET, and the reason is worth noting.
To ensure a fair comparison, we disabled several performance tests, particularly those related to recursive functions where PL.NET exhibited a significant performance advantage, often outperforming pl/pgsql by a factor of ten or more. While these tests demonstrated PL.NET's prowess, we wanted to maintain fairness in our benchmarking.
These excluded tests, such as recursive programming functions commonly used in functional programming, are important but not the primary use case. Thus, we turned them off for benchmarking purposes.
Remarkably, our performance was so robust that we found little need for optimization. We hadn't even begun performance tuning for PL.NET at this stage.
However, it's important to understand that in the grand scheme of things, pl/pgsql's slight performance advantage in procedural layers is overshadowed by PL.NET's overall application performance. PL.NET boasts a garbage-collected, JIT-compiled, multithreaded runtime—a stark contrast to pl/pgsql's simpler, single-threaded, and interpreted nature. When it comes to your application's overall performance, PL.NET has the upper hand.
While we acknowledge there's room for further optimization, even without it, we're neck and neck with pl/pgsql, making us highly competitive. When we do fine-tune those areas, PL.NET will undoubtedly outperform pl/pgsql, especially in scenarios where we currently outshine them.
In conclusion, PL.NET emerges as the top external stored procedural language, offering robust competition even against the native stored procedural language. When it comes to overall performance, PL.NET takes the lead. Moreover, we provide a wider range of native data type support, better testing, and improved API support. The choice is clear: PL.NET is the ultimate performer in PostgreSQL's procedural language landscape.