Benchmark Results: The Fastest Time-Series Database on Azure

Raw Results

Do It Yourself: RTABench on Azure

Explainer: RTABench

RTABench is an open-source, real-time analytics benchmark designed to measure how well a transactional database handles analytic queries, particularly those requiring joins and filtering over a normalized schema.

The dataset contains ~171 million events across 1,102 customers, 9,255 products, and 10,010,342 orders, providing a realistic, scalable application workload. RTABench supports a number of databases, and the benchmark has been written to take advantage of each database’s capabilities when appropriate, e.g., TimescaleDB features like hypertables, compression, and columnar storage.

Now that Tiger Cloud is launched on Azure, you can run these benchmarks yourself and observe comparable results. 

Setup: Client Host

1. For a client host, start a Standard_D2s_v3 instance running Linux (ubuntu 24.04) with 2 vCPUs and 8GB RAM. 

2. Increase its disk size to accommodate the data set.

Test 1: Tiger Cloud

1. Sign up for Tiger Cloud and select a “Real-time analytics” service type.

2. Spin up an 8 CPU 32GB dev service in Azure.

3. Note the connection string or save the config:

4. On the client host, git clone this fork of RTABench. The fork tweaks the benchmark invocation scripts to accept a connection string for Postgres rather than spinning it up with Terraform.
5. In the tigercloud-manual directory, edit benchmark.sh to provide your connection string.
6. To run the benchmark in the background and correct for inconsistent network connections between your cafe and your client host, use nohup and make it a background process:

When done, in addition to a verbose report, the output should contain query times measured in very few seconds. One line per query; each query runs three times. 

Note: During the initial data load phase of RTABench, your Tiger Cloud instance may scale up its storage capacity for the first time. A transient race condition can occur where Postgres reports disk space constraints before the storage expansion is fully recognized. This completes with an invalid result as the tables are not fully loaded. If there are disk space or restart errors in the output, reset the Tiger Cloud database using the included drops.sql script and re-run the benchmark. The second run will not require storage scaleup.

Test 2: Azure Database for Postgres 

Now that we have a Tiger Cloud baseline, let’s compare it to Azure Database for Postgres. Presuming this is naive vanilla Postgres, we don’t have any TimescaleDB specific features such as hypertables, let alone continuous aggregates or vectorized storage. We use the Postgres test in RTAbench for this.

1. In the Azure portal, create an Azure Database for Postgres Flexible Servers instance in the same region as the client host, matching compute and storage settings for the Tiger Cloud instance. It’s expensive, so don’t leave it running for a long time.

You can view the connection string from the Azure portal as well:

2. On the client host, in the postgres-manual subdirectory:

Edit benchmark.sh and provide the connection string

Use nohup and make it a background process:

After a while, your output should contain values measured in quite a few seconds.

Test 3: TimescaleDB Extension

The TimescaleDB extension that’s available with Azure Database for Postgres is the Apache 2 Edition. It lacks columnar storage, native compression, and incremental continuous aggregates. 

1. To enable the TimescaleDB extension on your Azure Database extension, click TIMESCALEDB on azure.extensions and shared_preload_libraries server settings:

This will require a restart of Postgres. That should take less than 5 minutes.

2. In the timescale-manual directory, edit benchmark.sh and provide the connection string.

Use nohup and make it a background process:

Examine the output. You may see errors around unsupported functions such as continuous aggregates. This is to be expected due to the limitations with Apache Licensed TimescaleDB.

Resetting Postgres

Between tests, and if you need to restart due to an issue, you can wipe Postgres clean as follows:

Analyzing the Results

RTABench includes query performance results in its output. Each query is run three times and performance is reported one line per query, one value per issuance. Output should be scanned for errors and warnings that invalidate the results. Usage of unsupported features, such as continuous aggregates on TimescaleDB Apache 2 or hypertables on Vanilla Postgres may also be reported as an error. Results should be sanity checked with our public RTABench reports.

For fun, you can upload the benchmark output files to an LLM and have a conversation. We were particularly amused at how excited Claude got by Tiger Cloud’s millisecond latency after seeing the Vanilla Postgres results:

Run Real-Time Workloads on Azure the Way They Were Meant to Run

Microsoft often recommends Azure Data Explorer for time-series workloads because of its rich user experience and optimizations for high-volume, timestamped data. We didn’t run that benchmark at this time because RTABench doesn’t yet support Kusto Query Language (KQL). Although the non-standard query language might be a compelling reason to keep time-series workloads in Postgres.

This benchmark makes the broader point clear. If you’ve been held back by slow queries, storage tradeoffs, or the limitations of the Apache 2 Edition on Azure Database for PostgreSQL, Tiger Cloud changes what’s possible on Azure. You get:

• Postgres you already know
• The full TimescaleDB feature set
• Azure-native deployment and billing

And you get performance that is consistently measured in milliseconds, not seconds or minutes.

Resources:

• Azure documentation
• Get started on Azure Marketplace

Questions or want to discuss your architecture? Talk to our solutions team.