Benchmarking Simplyblock Storage on ClickBench with PostgreSQL and DuckDB

As storage demands scale and workloads become increasingly performance-sensitive, the right infrastructure choices can drive massive gains in both throughput and efficiency. At simplyblock, we set out to validate the performance of our storage layer using the industry-standard ClickBench benchmark suite.

Thanks to the vast number of available databases supported databases, ClickBench is a perfect tool to run database benchmarks and adjust them to new environments quickly. We tested two popular databases—PostgreSQL and DuckDB—backed by simplyblock’s high-performance software-defined storage.

Test Environment

One of the major factors when running benchmarks is the environment used. Many original ClickBench results utilize AWS virtual machines or proprietary hardware. Simplyblock, however, used Google Compute Engine (GCP) to run the test. This was a cost-efficiency choice and doesn’t reflect any preference of GCP over AWS on simplyblock’s side.

Original Infrastructure: ClickBench

• PostgreSQL:
  • AWS instance type: c6a.4xlarge
  • 16 vCPUs (x86_64), 32 GB RAM
  • Amazon EBS storage volume
• DuckDB:
  • AWS instance type: c6a.metal
  • 192 vCPUs (x86_64), 384 GB RAM
  • Amazon EBS storage volume

Simplyblock-Backed Infrastructure

PostgreSQL runs:

• GCP Instance type: c3-standard-88
• 88 vCPUs (x86_64), 352 GB RAM
• 100 Gbit/s Tier 1 networking
• 6 simplyblock logical volumes, connected via NVMe over TCP, LVM-striped XFS volumes for WAL and table data, enabling maximum parallelism

⚠️ Note: Despite the larger instance size, vCPU and RAM usage were limited during the benchmark to match the original ClickBench spec (16 vCPUs, 32 GB RAM) to ensure a fair comparison. The larger instance was chosen solely to meet GCP’s higher network throughput requirements.

Simplyblock storage cluster:

• 3× c4a-standard-64-lssd instances, each with:
  • 64 ARM cores (AARCH64, Google Axion)
  • 256 GB RAM
  • 14x Local SSDs (NVMe, 375 GB each)
  • 75 Gbit/s Tier 1 networking
• Each host ran 2 simplyblock nodes, totaling 6 distributed storage nodes

🐘 PostgreSQL: Raw and Indexed Queries

Test Scenarios:

• PostgreSQL without indexes
• PostgreSQL with indexes

Each was tested against the given baseline on ClickBench (most likely AWS EBS) with a simplyblock-backed storage. CPU and RAM was limited. No other configuration changes were applied.

Key Observations:

✅ Simplyblock reduced the benchmark runtime by up to 18x, with significant improvements even when indexes were used.

✅ Simplyblock reduced the runtime of certain queries by over 5000x with an average of over 500x.

✅ Simplyblock reduced load time by up to 47%, thanks to parallel ingestion on NVMe-backed volumes.

ClickBench Results: PostgreSQL without Indexes

This benchmark compares runs for PostgreSQL without indexes on the baseline Amazon EBS vs. simplyblock storage.

Execution ratios range from 2x to over 5000x, with cold queries consistently being 10–270x faster and warm queries showing especially high improvements in complex queries.

When PostgreSQL is forced to scan tables (due to lack of indexes), storage performance becomes the dominant factor. That said, PostgreSQL’s performance is typically limited by disk I/O.

Simplyblock’s high-bandwidth, parallelized storage backend drastically reduces execution time for nearly every query. Our NVMe-over-TCP-based storage offers much higher throughput and parallelism compared to AWS EBS, translating to significant speedups, especially in I/O-heavy workloads.

ClickBench Results: PostgreSQL with Indexes

In this test, PostgreSQL used indexes, reducing the storage dependency but increasing the load time significantly. Yet, simplyblock still provided 2–25x speedups on many cold and warm queries. Some queries saw near parity or slight regressions, mostly due to PostgreSQL’s internal optimizations masking storage advantages.

Even when indexes limit I/O needs, simplyblock still enhances performance by ensuring fast data fetches and load operations. This proves its value even in optimized, production-like scenarios where queries use indexes extensively.

Interestingly, some queries are faster without indexes. This shows the benefit of using extremely fast storage underneath PostgreSQL, with the option to reduce DDL complexity and remove the computational overhead of the indexing.

Simplyblock and PostgreSQL

Simplyblock’s storage layer dramatically improves PostgreSQL performance in both raw and indexed query scenarios.

With no indexes, query execution was up to 5000x faster, and overall query runtime was reduced by 18x on average.

Even with indexes (where storage bottlenecks are less prominent), Simplyblock still reduced query time by up to 20x and cold-start load times by 47%.

🦆 DuckDB: Single File vs Partitioned Parquet

Test Scenarios:

• DuckDB reading a single Parquet file
• DuckDB reading partitioned Parquet files
• Each was tested against the provided baseline with a simplyblock-backed storage

Key Observations:

✅ DuckDB is very high performance across all tests and independent of the underlying storage. However, simplyblock-backed DuckDB showed faster data load times, slightly faster cold queries, and sustained competitive warm-query latencies, even in more demanding partitioned workloads.

✅ Simplyblock increases query speed on cold benchmark runs by up to 27x.

ClickBench Results: DuckDB with Single Parquet File

When using DuckDB on top of simplyblock, cold queries are accelerated by up to 26x and showed mild improvements in warm query times (~1.1–2x).

This shows that simplyblock enhances first-time access (e.g., initial analytics or scans), which is often bottlenecked by storage in columnar file formats like Parquet.

This is especially interesting in the context of massive data sets where data typically doesn’t fit into memory and need to be read from the backing storage (being a cold-read). Simplyblock ensures fast and consistent access times no matter if data is already in RAM or still on disk.

ClickBench Results: DuckDB with Partitioned Parquet Files

With partitioned Parquet files, simplyblock showed significant cold-query improvements, up to 22x. Warm-query speedups were smaller (~1.1–2x), and a few regressions were likely due to variance in CPU-bound operations.

For complex, partitioned datasets, faster storage helps DuckDB ingest and query data more efficiently, especially when cold-starting or scanning wide partitions in analytics pipelines.

Again, with increasing data set sizes, the chance that the required data is already in RAM decreases dramatically. Here is where simplyblock really shines and increases the load performance when cold-reads happen.

Simplyblock and DuckDB

DuckDB, known for being compute-bound, saw modest but consistent improvements using simplyblock. However, when data doesn’t reside in memory yet, simplyblock’s extreme storage performance leads up to 27x faster cold queries, faster data loads, and lower latency for partitioned datasets.

DuckDB is fast by design, so differences were narrower. However, on cold starts (when data must be read from storage), simplyblock’s faster I/O showed a clear edge. It proves that even CPU-heavy analytics engines benefit from better storage in real-world conditions.

Simplyblock: Performance of Local Disks with the Flexibility of Distributed Storage

Simplyblock combines the performance of local NVMe disks with the flexibility of distributed storage. In all tests (PostgreSQL and DuckDB), it consistently performs better, particularly in I/O-heavy workloads.

The benchmarks validate that using simplyblock can dramatically reduce query runtimes, speed up ingestion, and make analytics pipelines far more efficient—whether in transactional databases or analytical engines.

The ClickBench benchmark results highlight the strength of simplyblock’s architecture in real-world data-intensive workloads.

• PostgreSQL, typically limited by I/O throughput on EBS volumes, benefited dramatically from the NVMe-backed, high-bandwidth simplyblock cluster.
• DuckDB workloads, while primarily CPU- and memory-bound, still saw tangible benefits in faster data loading and parallel query performance. Especially on the initial cold runs, where storage performance is the limiting factor in many situations.

Whether you’re scaling analytics pipelines or need predictable performance in transactional workloads, simplyblock provides the performance of local disks with the flexibility of distributed block storage, and can be deployed on your “cloud” of choice (public, private, or on-premises) without vendor lock-in.

Bring your data infrastructure to the modern age with simplyblock.

Topics

Share blog post

Tags