• A Quick Word Before We Dive In
• Why Benchmark Matters
• About the Benchmarking Tool - pgbench
• Benchmarking
• Repository & Reproducibility
• Environment
• Hardware / Configuration:
• Executions
• Databricks Lakebase - 240s Run:
• Databricks Lakebase - 180s Run:
• AWS Aurora (PGSQL) - 240s Run:
• AWS Aurora (PGSQL) - 180s Run:
• Interpreting pgbench summary
• Workload details
• Results at-a-Glance (4 Million‑Row Dataset, 180 Clients)
• Key take-aways:
• What Else is Observed?
• Deep‑Dive: Parameter Tuning
• Observability Shortcuts
• Lakebase UI
• Aurora
• Conclusion - Key Takeaways and What’s Next
• Caveats & Future Work
• References

A Quick Word Before We Dive In

In Part-1 we introduced Databricks Lakebase architecture — essentially a PostgreSQL‑compatible OLTP layer that sits next to Delta tables inside the Databricks Lakehouse. If that’s new to you, start here and learn more on how to spin it up, connect a psql client, and load a starter dataset into its Postgres‑compatible front‑end. With the environment in place, it’s time to answer the next logical question:

“How does Lakebase behave under real OLTP pressure, and how does that compare to a well‑known managed Postgres?”

This article walks through the methodology, command lines, and metrics captured during benchmarking.

Why Benchmark Matters

Anecdotes and marketing slides are helpful, but nothing beats an empirical workload run under controlled conditions. Benchmarks reveal:

It surfaces trade‑offs and behavioural differences so you can decide what matters for your application. With that in mind, this article records what we observed when running the same pgbench script against:

• Databricks Lakebase
• AWS Aurora (PostgreSQL engine)

About the Benchmarking Tool - pgbench

You can benchmark a Postgres‑compatible engine in many ways: custom micro‑services, JVM stress tests, and so on. For this study we use pgbench, the canonical tool that ships with PostgreSQL itself:

• Generates a mix of single‑row selects, updates, and account transfers.
• Lets you plug in a same script to better mimic your schema (can be found in the repo below).
• Produces TPS and latency histograms that are easy to parse and visualise.

Benchmarking

Let's deep dive into the benchmarking of Databricks Lakebase with AWS Aurora

Repository & Reproducibility

Complete procedure for performing the benchmark of Databricks Lakebase is available in the github repo: https://github.com/dediggibyte/diggi_lakebase

Benchmark repo — README

Environment

Hardware / Configuration:

Executions

Databricks Lakebase - 240s Run:

pgbench -n \
  -h "$LAKEBASE_HOST" -p "$LAKEBASE_PORT" -U "$PGUSER" \
  -f custom_test.sql \
  -T 240 \
  -c 180 \
  -j 6 \
  "$PGDATABASE"

Environment variables exported — Lakebase (240s run)

Databricks Lakebase - 180s Run:

pgbench -n \
  -h "$LAKEBASE_HOST" -p "$LAKEBASE_PORT" -U "$PGUSER" \
  -f custom_test.sql \
  -T 180 \
  -c 180 \
  -j 6 \
  "$PGDATABASE"

Environment variables exported — Lakebase (180s run)

AWS Aurora (PGSQL) - 240s Run:

pgbench -n \
  -h "$AURORA_HOST" -p "$AURORA_PORT" -U "$PGUSER" \
  -f custom_test.sql \
  -T 240 \
  -c 180 \
  -j 6 \
  "$PGDATABASE"

Environment variables exported — Aurora (240s run)

AWS Aurora (PGSQL) - 180s Run:

pgbench -n \
  -h "$AURORA_HOST" -p "$AURORA_PORT" -U "$PGUSER" \
  -f custom_test.sql \
  -T 180 \
  -c 180 \
  -j 6 \
  "$PGDATABASE"

Environment variables exported — Aurora (180s run)

Interpreting   pgbench   summary

Workload details

Results at-a-Glance (4 Million‑Row Dataset, 180 Clients)

Key take-aways:

• Flat lines: Both engines kept TPS almost flat between 180s and 240s, indicating the buffer cache stayed warm.
• Latency Delta: Lakebase averaged ~15 ms faster per transaction at the same concurrency.
• Clean runs: Zero failed or aborted transactions across all tests.

What Else is Observed?

1. Region affinity: Our first Lakebase attempt used a driver VM in another AZ; TPS cratered by ~50 %. Lesson: keep client and database in the same AZ for OLTP benchmarks.
2. Data‑volume resilience: A pilot with only 1M rows clocked 1880 TPS on Lakebase. Bumping to 4 M rows shaved off ~8 % — a healthy sign.
3. Connection spikes: Spooling up 180 new sessions took 20–25 s on both engines. Harmless for steady workloads; something to watch for burst‑and‑idle patterns.

Deep‑Dive: Parameter Tuning

Observability Shortcuts

Lakebase UI

Monitor ▶︎ Lakebase shows live TPS, P95 latency, active connections, and storage utilisation%.

Databricks Lakebase Metrics

Aurora

CloudWatch metrics (DatabaseConnections, SelectLatency, CommitLatency) plus pg_stat_statements for top queries.

AWS Cloudwatch Metrics

Conclusion - Key Takeaways and What’s Next

In this post we ran a head‑to‑head pgbench benchmark on a 4 million‑row dataset—same script, same client count—against Databricks Lakebase and AWS Aurora (PostgreSQL). From seeding data to reading the latency histogram, a few things stood out:

• Identical workload, distinct personalities: Lakebase’s vectorised execution path edged out Aurora on average latency (~15 ms per transaction) while both engines held steady throughput around 1.5–1.7 k TPS with zero failures.
• Topology still matters: Keeping the driver VM in the same AZ as the database doubled Lakebase TPS versus an earlier cross‑AZ trial — a reminder that network round‑trips still rule OLTP.
• Good defaults get you far: Out‑of‑the‑box settings (no shared_buffers tuning, no custom autovacuum) were enough to clear enterprise‑grade throughput on both platforms.
• Connection spikes are the new cold start: Spooling up 180 sessions took ~20–25 s for both engines. If your workload bursts from zero, a pooler is mandatory.
• Schema awareness pays dividends: Lakebase lost only ~8 % TPS when scaling from 1 M to 4 M rows, underscoring the value of tight indexing over brute‑force hardware.