DataScaleFail #14: PostgreSQL, PostgreSQL, and more PostgreSQL

The Price of Inertia: Why Legacy AWS RDS PostgreSQL Instances are Costing Your Business Performance

Selecting cloud database hardware often feels like an exercise in faith rather than empirical engineering. In this analysis, we explore the performance variables of Amazon RDS PostgreSQL across two major architectural families (x86-64 based Intel Xeon and ARM64-based AWS Graviton) as well as two CPU generations.

Utilizing a standardized BenchBase TPC-C workload, our results demonstrate that instances with newer CPU generations deliver measurable latency cuts and throughput gains at near-identical baseline costs. We also highlight that the observed performance leaps are markedly asymmetric with more pronounced gains for the Graviton instances. If you are running legacy database instances, you are actively overpaying for underperformance. Also, our results show that Graviton offerings currently yield the more optimal performance-per-dollar ratio for AWS RDS PostgreSQL.

> read more

PostgreSQL: Extensions for Analytical Workloads

Traditionally, transactional and analytical database workloads are separated to avoid resource contention and to take advantage of dedicated database engines optimized for the specific use case. This comes with the engineering overhead of managing two separate data storages, database engines, and an external synchronization pipelines in between.

That's why alternative approaches to the traditional ETL-based data warehousing architecture have emerged. Hybrid transactional/analytical processing (HTAP) architectures run analytical workloads directly on operational data in a single engine, while Databricks's recent lake transactional/analytical processing (LTAP) architecture unifies the data storage. For PostgreSQL, analytical extensions follow the HTAP idea by modifying the storage layer or query execution paths and enable complex analytical queries natively in PostgreSQL. This post examines the technical mechanisms of these analytical variants and extensions to evaluate how they handle intensive read-heavy workloads within Postgres.

> read more

PostgreSQL Vector Search Extensions

Following a lot of hype surrounding standalone vector databases, many in the industry have been realizing that such specialized, dedicated engines do not always fit the bill. Instead, keeping your vectors next to your relational data is oftentimes more manageable and straightforward.

In a series of blog posts, we will explore how appropriate extensions allow you to turn PostgreSQL into a hybrid database that supports both relational data and vectors. In this first part, we take a look at the essential concepts of vector databases and what the PostgreSQL ecosystem provides for this purpose. Later in a second part, we will dive into the performance characteristics of different vector extensions and how they compare against other offerings.

> read more

Enjoyed this edition?

Thanks for reading this edition of DataScaleFail. Want more? Check out the previous edition or the archive. Share this newsletter with your team if they are evaluating database technologies or making infrastructure decisions.

We'd love to hear from you:

• Are you running Cassandra 5 in production and have a tuned configuration that outperforms our results? Submit it to us and we'll benchmark it.
• Interested in seeing benchmark results for a specific PostgreSQL DBaaS provider? Vote in our community poll or reach out directly.
• Got questions or a benchmark you’d like us to cover? Get in touch.

Sign up for the next issue of DataScaleFail to stay updated on new benchmarks, database releases, and performance insights that matter for your infrastructure. Until next time, keep questioning your results.