🚀 MySQL vs PostgreSQL vs SingleStore: 100M Record Analytics in Docker – Who Wins?

🚀 MySQL vs PostgreSQL vs SingleStore: 100M Record Analytics in Docker – Who Wins?

As data volumes skyrocket and analytical needs grow more complex, choosing the right database engine becomes mission-critical. I recently explored a benchmark by SingleStore that compared MySQL, PostgreSQL, and SingleStore using 100 million rows in a Dockerized environment. The results are eye-opening—especially if your business runs on large-scale analytics.


🔍 Benchmark Setup

The test simulated a fintech-style application, with users, accounts, and transactions modeled relationally. Here’s what was tested:

✅ Workloads Simulated

  1. Rolling transaction volume per user over the last 30 days

  2. Top transfer recipients in the system

  3. Complex JOINs and aggregations across tables with 100M+ rows

  4. Docker-based, uniform resource-constrained setup (4 vCPUs, 8 GB RAM)

🧪 Tools Used

  • Data Generator: Node.js and Go

  • Datasets: Synthetic but structurally realistic

  • Queries: SQL with indexes applied where relevant

  • Environment: Docker with strict CPU/memory limits to simulate real-world deployment constraints


🧪 One Real-World Scenario: “Total Transaction Volume in Last 30 Days”

This benchmark mimicked a fintech analytics query:

“Calculate the total transaction volume per user over the last 30 days, ordered by amount.”

Schema Involved:

  • users(id, name)

  • accounts(id, user_id)

  • transactions(id, account_id, amount, created_at)

Query Pattern (simplified SQL):

Benchmark Results Visualization


⚡ The Results

DatabaseQuery Execution TimeVerdictSingleStore~20.38 seconds🔥 Fastest, designed for real-time analyticsPostgreSQL~40.58 seconds🟡 Reliable, but not optimal at this scaleMySQL⏳ Timed out (>5 min)🔴 Not suitable for this workload


🧠 Key Insights

1. SingleStore: Built for Modern Analytics

SingleStore outperformed both PostgreSQL and MySQL by a wide margin. Designed as a distributed SQL database, it leverages columnstore indexes, vectorized execution, and parallel processing to deliver sub-second performance on complex queries—even over massive datasets.

“This is what real-time OLAP + OLTP looks like when unified into one platform.”

2. PostgreSQL: Mature but Linear

PostgreSQL handled the queries respectably. It's a battle-tested, standards-compliant RDBMS that scales fairly well—but linearly. As table sizes and query complexity grow, performance degradation is noticeable without significant tuning (e.g., materialized views, partitioning, or CTEs).

“Great for many workloads, but might require manual optimization under pressure.”

3. MySQL: Hits a Wall

MySQL couldn't finish the complex queries in a reasonable time. Despite being one of the most popular databases in the world, MySQL lacks advanced query planning and struggles with JOIN-heavy analytics, especially when datasets cross 8-figure rows.

“Great for simple CRUD and transactional workloads. Not made for analytics.”


🔧 What Developers & Architects Should Take Away

  • If your use case involves real-time dashboards, data streaming, or reporting over large tables, you need a database that scales intelligently.

  • SingleStore provides concurrent OLTP + OLAP performance. You don’t need a separate warehouse or ETL layer.

  • PostgreSQL is still a solid choice—but consider tools like Citus or Timescale if scaling vertically becomes painful.

  • MySQL is best reserved for transactional workloads or paired with analytics-optimized systems like ClickHouse or Apache Druid.

📦 Run It Yourself – Open Source Benchmark

You don’t have to take their word for it.

SingleStore made the full benchmarking repo available on GitHub: ➡️ singlestore-labs/demo-docker-benchmarking-battle

It includes:

  • Docker Compose setup for all three DBs

  • Synthetic data generator

  • Index and query examples

  • Benchmarking scripts

You can fork it, modify the schema, and benchmark your own workloads!


🧩 Beyond Performance: Operational Simplicity

Another benefit that stood out: SingleStore’s operational simplicity.

  • No separate OLTP/OLAP layers

  • Built-in replication and failover

  • Ingest + query without pipeline delays

  • Seamless Kubernetes support

That means less DevOps overhead, faster delivery cycles, and happier analysts.


🧠 Final Thoughts

🚨 With businesses becoming increasingly data-driven, traditional monolithic RDBMSs are being stress-tested like never before.

If your team is working with:

  • Real-time analytics

  • Heavy JOINs & aggregations

  • Streaming + batch fusion

  • Growing datasets (100M+ rows)

...it might be time to go beyond PostgreSQL and MySQL. This benchmark clearly illustrates the value of newer SQL engines like SingleStore that are designed with today’s analytics needs in mind.


💬 Over to You

What’s your stack for handling large-scale analytics? Have you hit similar performance bottlenecks with PostgreSQL or MySQL? Tried SingleStore or any HTAP systems like ClickHouse, DuckDB, or Apache Pinot?

I’d love to hear your experience—drop your thoughts in the comments! 👇

To view or add a comment, sign in

Others also viewed

Explore topics