Timescale used 95 % less disk than Amazon RDS for PostgreSQL, thanks to Timescale’s native columnar compression, which reduced the size of the test database from 159 GB to 8.6 GB. When we ran a variety of time-based queries on both databases, ranging from simple aggregates to more complex rollups through to last-point queries, Timescale consistently outperformed Amazon RDS for PostgreSQL in every query category, sometimes by as much as 350x (you can see all of the results in the Benchmarking section). When we ingested data in both Timescale and Amazon RDS for PostgreSQL (using gp3 EBS volumes for both), Timescale was 34 % faster than RDS for 4 vCPU and 44 % for 8 vCPU configurations. Time-Series Data Benchmarking: A Sneak Previewįor those who can’t wait, here’s a summary: for a 1 TB dataset with almost 1 billion rows, Timescale outperforms Amazon RDS for PostgreSQL with up to 44 % higher ingest rates, queries running up to 350x faster, and a 95 % smaller data footprint. You will find all the details of our comparison and all the information required to run the benchmark yourself using the Time-Series Benchmarking Suite (TSBS). In this blog post, we share a benchmark comparing the performance of Timescale to Amazon RDS for PostgreSQL. Timescale has always strived to enhance PostgreSQL with the ingestion, query performance, and cost-efficiency boosts that developers need to run their data-intensive applications, all while providing a seamless developer experience with advanced features to ease working with time-series data.īut don’t take our word for it-let the numbers speak for themselves. Since Timescale is still PostgreSQL and already in AWS, the transition from RDS is swift: Timescale integrates with your PostgreSQL-based application directly and plays nicely with your AWS infrastructure. Timescale runs on AWS, offering hosted PostgreSQL with added time-series superpowers. A time-series database is discussed, but the developers and the application still rely on PostgreSQL features.ĭoes it sound familiar? It’s usually at this stage when developers realize that Amazon RDS for PostgreSQL is no longer a good choice for their applications, start seeking alternatives, and come across Timescale.
As the database becomes a bottleneck, it becomes a target for optimization.Amazon RDS for PostgreSQL works well at first, but as the volume of time-series data in their database grows, they notice slower ingestion, sluggish query performance, and growing storage costs.
The team is focused on shipping features, so they choose the path of least resistance-Amazon RDS for PostgreSQL. At the start of a project, developers choose PostgreSQL because it’s a database they know and love.When we talk to these customers, we often see a pattern: Timescale fits them perfectly, and this article will present benchmarks that help explain why. They need a solution that will let them keep using PostgreSQL while not blocking them from getting value out of their time-series data. These developers usually struggle with performance issues on ingest, sluggish real-time or historical queries, and spiraling storage costs. Since we launched Timescale, our cloud-hosted PostgreSQL service for time-series data and event and analytics workloads, we have seen large numbers of customers migrating onto it from the general-purpose Amazon RDS for PostgreSQL.
0 kommentar(er)
