You know that moment when your team finally decides to move your PostgreSQL databases to Kubernetes? Everyone’s excited about the scalability and flexibility, but then someone asks the question that keeps you up at night: “Which storage are we going to use?”
It’s not just about picking any storage solution. Your database is the heart of your application, and if it can’t handle the load or—worse—loses data, you’re the one getting the phone call in the middle of the night. We’ve all been there, staring at performance graphs that look more like a roller coaster than the steady line you were hoping for.
That’s exactly why we decided to put the most popular storage solutions through their paces. We conducted a benchmark study to evaluate the performance of various open source and commercial storage solutions using the Percona Operator for PostgreSQL on Kubernetes. Testing focused on understanding how these solutions handle PostgreSQL workloads, highlighting their efficiency and suitability for different scenarios.
Testing overview
The benchmarking tests were conducted on AWS EKS (version 1.29.4) using i4i instances to leverage local storage. The following storage solutions were tested:
- OpenEBS
- Rook
- Lightbits
- Portworx
- AWS EBS volumes
Tools used:
- FIO: For raw I/O benchmarking (measuring IOPS, bandwidth, and latency).
- pgbench: For simulating PostgreSQL workloads and capturing transactional performance metrics.
If you’d like to reproduce these tests or explore the setup in more detail, you can find our test scripts on GitHub.
Testing scenarios:
- Storage I/O testing: This phase evaluated the raw performance of each storage solution, focusing on metrics such as IOPS, bandwidth, and latency. These tests provided insights into how each storage type handles basic read/write operations.
- Low memory allocation: PostgreSQL Pods were configured with reduced memory and shared buffers, emphasizing reliance on disk I/O. This setup simulated scenarios where the database’s ability to handle heavy disk activity is critical.
- High memory allocation: In this phase, PostgreSQL Pods were provided with larger shared buffers and higher memory limits, reducing dependence on disk I/O. The goal was to measure how storage performance changes when PostgreSQL can utilize memory more efficiently.
Key findings
Here’s the thing about benchmarks: everyone wants to know who “won.” But real life isn’t that simple. What we found is that the right storage depends entirely on what your PostgreSQL database is actually doing.
- OpenEBS turned out to be the speed demon when PostgreSQL was doing lots of random reads and writes. You know those workloads where users are constantly querying different parts of your database? OpenEBS handled that beautifully, consistently delivering higher transaction throughput when memory was tight. If your application involves lots of user interactions hitting different data patterns, this matters.
- Portworx showed its strength with the heavy lifting—sequential operations and bulk data processing. Think data imports, batch jobs, or analytics queries that churn through large datasets. When your PostgreSQL instance needs to move lots of data efficiently, Portworx delivered.
- AWS EBS was the steady performer. Not always the fastest, but consistently reliable across every scenario we threw at it. Sometimes boring is exactly what you want from your storage layer. No surprises, no weird performance drops—just solid, predictable performance.
- Lightbits gave us consistent results across the board. While it didn’t dominate any particular workload, it handled everything competently. For teams that need predictable performance without having to optimize for specific use cases, that consistency has real value.
- Rook struggled when things got busy. Under higher loads with more concurrent connections, we saw performance drop off. It might work well for smaller deployments or development environments, but production workloads with serious concurrency demands might leave you disappointed.
The memory plot twist
Here’s something interesting we discovered: When PostgreSQL had plenty of memory to work with, the performance differences between storage solutions narrowed significantly. It’s a good reminder that sometimes the best storage optimization is simply giving PostgreSQL enough RAM to avoid hitting storage as much in the first place.
Key observations: Get the report
The truth is, there’s no universal “best” storage for PostgreSQL on Kubernetes. The right choice depends on your specific workload patterns, budget constraints, and what keeps your team up at night.
What our testing did confirm is something important: PostgreSQL absolutely can deliver excellent performance on Kubernetes when you pair it with appropriate storage. The key is understanding your workload and choosing storage that complements it.
Get the full picture
We’ve put together a comprehensive report with all the detailed benchmarks, test methodologies, and specific performance metrics from this study. If you’re making storage decisions for your PostgreSQL deployment, you’ll want to see the complete data.
This benchmark study also highlights how the Percona Operator for PostgreSQL handles these various storage solutions reliably, helping teams deploy and manage high-performance PostgreSQL clusters on Kubernetes without the operational headaches.
See the complete benchmark report and detailed performance analysis
Thanks for sharing this.
The last option i.e. Rook – is it the same as ODF? If no, any reason to not test ODF given that it comes from RHEL and seems to be becoming a standard quickly.
Thanks for sharing this.
Does Rook refer to Ceph, or is it something else? If it’s something else, is there a specific reason why Ceph/ODF was not tested, considering it is becoming a standard?