PostgreSQL vs MySQL vs MongoDB vs Cassandra vs DynamoDB - Database Reality Check

Look, every database vendor talks about being "serverless" these days. But I've run production systems on all of these, and I'll save you the suspense: only one actually delivers on the promise.

DynamoDB: Actually Built for This

🗄️ DynamoDB: The True Serverless Option

DynamoDB is the only database in this comparison designed from day one for serverless workloads. When AWS says "zero administration," they mean it. You literally cannot access the underlying servers - they don't exist from your perspective.

AWS Finally Cut DynamoDB Prices (About Fucking Time): AWS reduced DynamoDB on-demand pricing by 50% in late 2024. Took them long enough - we were getting murdered on costs. This actually makes DynamoDB competitive with managed PostgreSQL, which nobody saw coming. Catch? You still gotta wrap your head around single-table patterns that'll make SQL developers cry.

Real-world serverless performance: DynamoDB handles traffic spikes from 10 requests per second to 40,000 requests per second without any configuration changes. The auto-scaling is transparent - you see the cost increase in your bill, not downtime in your monitoring dashboard.

The DynamoDB tax: Single-table design patterns require rethinking your entire data model. SQL joins become application logic. Transactions are limited to 25 items across 4MB. If your data model requires complex relationships, DynamoDB becomes painful fast.

Aurora Serverless: PostgreSQL/MySQL with Training Wheels

☁️ Aurora: Serverless with Asterisks

Aurora Serverless v2 (finally fucking stable as of mid-2024) tries to make PostgreSQL and MySQL serverless. It auto-scales between 0.5 and 128 ACUs (Aurora Capacity Units), with each ACU representing roughly 2GB of memory and corresponding CPU.

The scaling reality: Aurora takes way too long to scale when you actually need it. We hit the front page of HN and the first wave of users got connection timeouts while Aurora was still figuring out if it needed more capacity. Took maybe half a minute which might as well be forever when your site's blowing up.

Cost structure: Aurora Serverless runs around a dollar per ACU-hour, but the billing gets weird fast. Our database bill started somewhere around $2,500/month, now we're pushing $4k and honestly not sure why. Could be background jobs keeping the thing warm, or maybe all those read replicas we forgot about. The "pay only when active" promise is marketing bullshit when you've got cron jobs running constantly.

PostgreSQL on Aurora: I'm running PostgreSQL 17 and it's been solid. Aurora gives you the latest versions plus whatever extensions you need - pg_vector if you're doing AI stuff. Way faster than regular RDS, like 3x better, but you pay for it.

MySQL on Aurora: Less compelling unless you're stuck with legacy MySQL. If you're starting fresh, just use PostgreSQL.

MongoDB Atlas: NoSQL Serverless (With Asterisks)

🍃 MongoDB: NoSQL with Expensive Scaling

MongoDB Atlas Serverless launched with great fanfare but has strict limitations that make it unsuitable for production workloads above toy scale. The 1TB storage limit and connection throttling hit faster than you'd expect.

Atlas pricing is a trap: M10 instances are completely useless for anything real - like $57/month to host a glorified to-do app. Production requires M30+ and we're paying something like $1,200/month with backups and monitoring. Maybe more now, I stopped looking at the MongoDB line item because it just makes me angry.

Performance improvements: The latest MongoDB is supposedly faster, but it requires WiredTiger cache tuning that nobody on my team wants to deal with. Atlas handles this automatically, which is nice, but you're paying a premium for that hand-holding.

Scaling reality: MongoDB sharding works well for write scaling but introduces operational complexity. Choosing the wrong shard key is a permanent mistake - you cannot change it without a full migration. Atlas makes sharding easier but doesn't eliminate the fundamental data modeling challenges.

Cassandra: Distributed by Design, Serverless by Accident

💍 Cassandra: The Ring Architecture

Cassandra's latest version with SAI (Storage-Attached Indexes) finally lets you do multi-column queries without the traditional "model your data for your queries" nightmare. This makes Cassandra slightly less insane for regular developers.

DataStax Astra DB provides the closest thing to "serverless Cassandra." You get the linear scaling and fault tolerance of Cassandra without managing JVM heap sizes or compaction strategies. Pricing starts at $0.10 per read/write operation with a $25 minimum monthly charge.

Serverless characteristics: Cassandra naturally scales horizontally without downtime. Adding nodes increases capacity linearly. The architecture is inherently "serverless" in that no single node is special - lose any node and the cluster continues operating.

The complexity trade-off: Even with Astra DB, you still need to understand Cassandra's data modeling patterns. Consistency levels, partition keys, and tombstone accumulation remain operational concerns. This isn't "zero administration" like DynamoDB.

PostgreSQL and MySQL: Server-Based Thinking in Serverless Clothes

🐘 PostgreSQL & MySQL: Old School Reliability

Traditional PostgreSQL/MySQL deployment patterns don't translate well to serverless architectures. Connection pooling, read replicas, and manual scaling decisions require traditional database administration skills.

Managed options improve the story:

• **Amazon RDS Proxy** helps with connection pooling for Lambda functions
• **Google Cloud SQL** offers automatic scaling for read replicas
• **Azure Database for PostgreSQL** provides built-in connection pooling

Connection limits still bite: PostgreSQL defaults to 100 concurrent connections. Each Lambda execution creates a database connection. Under load, you'll hit connection limits and get "FATAL: sorry, too many clients already" - PostgreSQL's way of saying "fuck you, scale better."

Learned this one the hard way during our product launch when everything went to shit at once. Had like 400+ Lambdas or some crazy number all trying to connect at once - everything went to shit simultaneously. Still have PTSD from that 'FATAL: sorry, too many clients' error message. RDS Proxy helps but adds latency and costs $0.015/hour per connection.

Also had some weird connection pooling issue during migration where connections would just... disappear? Took us 3 hours on Stack Overflow to figure out it was some timeout setting nobody knew about.

Current reality:

• PostgreSQL: Works great, latest version has better performance
• MySQL: Fine if you're stuck with it
• Both offer JSON columns for flexible schemas
• Neither offers true auto-scaling without rethinking your architecture

The Real Serverless Database Decision Matrix

Choose DynamoDB if:

• Your application can work with NoSQL patterns
• Traffic is unpredictable (spiky or seasonal)
• You want true zero administration
• Budget predictability matters less than operational simplicity

Choose Aurora Serverless if:

• You need complex SQL queries and relationships
• Your team knows PostgreSQL/MySQL already
• You can tolerate 15-30 second scaling delays
• Budget allows for $3,000+ monthly database costs

Choose MongoDB Atlas if:

• Your data model fits document patterns naturally
• You need rapid development with schema flexibility
• Your team prefers NoSQL query patterns
• You're building content management or catalog systems

Choose Cassandra/Astra if:

• You need massive write throughput (100k+ ops/sec)
• Global distribution is required
• Eventual consistency is acceptable
• You have time-series or IoT data

Choose traditional PostgreSQL/MySQL if:

• "Serverless" is marketing fluff for your use case
• You need predictable performance and costs
• Your workload is steady-state with known patterns
• You have existing database administration expertise

What "Serverless" Actually Costs in 2025

💰 The Real Cost Story

The pricing models vary dramatically, and the marketing numbers don't reflect real-world costs:

DynamoDB: Our bill runs around $200/month but jumped to $800 when we got featured somewhere. Then went back down. Then spiked again for no fucking reason. Hard to predict.

Aurora Serverless: Started at $2,500/month, now we're at $4k and honestly not sure why.

MongoDB Atlas: M10 instances are useless for anything real. We're paying around $1,200/month with backups and monitoring - I think? Could be $1,500 by now, I stopped looking at the bill.

Cassandra Astra: $25 minimum monthly but scales with usage. Good if you have high transaction volumes, expensive for typical web apps.

Traditional managed databases: RDS PostgreSQL starts around $200/month but you need read replicas and monitoring to match what the serverless options give you automatically.

The hidden costs include data transfer (can double your bill), backup storage, monitoring tools, and the engineering time spent on database operations versus application development.

But understanding costs is only half the battle. The real test comes when you need to migrate between these systems - which is when most companies realize they're completely fucked.

After seeing the serverless promises and cost realities, many companies decide to migrate. But moving between these databases isn't just a technical challenge - it's a complete architectural shift that most teams underestimate. Here's what actually happens when companies attempt these migrations in production.

The DynamoDB Migration Reality

🔄 From Relational to Single-Table Hell

From SQL to DynamoDB: This isn't migration - you're rewriting your entire fucking app. Every company I know spent at least a year redesigning everything.

Single-table design shock: Instead of normalized tables with foreign keys, DynamoDB requires denormalized data structures where related entities are stored together. A typical e-commerce application with Users, Orders, and Products tables becomes a single table with complex partition and sort key patterns.

// Before (SQL): Simple join query
SELECT u.name, o.total, p.title 
FROM users u 
JOIN orders o ON u.id = o.user_id 
JOIN products p ON o.product_id = p.id
WHERE u.email = 'customer@example.com'

// After (DynamoDB): Single table with GSI
{
  PK: "USER#customer@example.com",
  SK: "PROFILE",
  name: "John Doe",
  // ... user data
}
{
  PK: "USER#customer@example.com", 
  SK: "ORDER#2025-09-01#12345",
  total: 149.99,
  product_title: "MacBook Pro", // denormalized
  // ... order data
}

The Netflix case study: Netflix spent years migrating from Oracle to DynamoDB - they basically rebuilt their entire data architecture. They didn't just change databases, they rewrote every service that touched user data. Google their case study if you want the details. End result? 99.99% availability and handling Black Friday traffic spikes without pre-provisioning capacity.

Common migration failures: Companies that try to replicate their SQL data model in DynamoDB end up with hot partitions, expensive scan operations, and worse performance than their original database. The migration succeeds only when you design for DynamoDB's strengths.

Aurora Serverless: The "Safe" Migration Path

PostgreSQL to Aurora: This is the smoothest path. Aurora PostgreSQL is wire-compatible with standard PostgreSQL, so your apps work without code changes. AWS DMS handles the data transfer.

Performance improvements: We saw about 3x better throughput after moving to Aurora. The distributed storage layer eliminates I/O bottlenecks that kill standard PostgreSQL performance.

Hidden migration costs:

• RDS Proxy setup ($0.015/hour per connection): Required for Lambda functions to avoid connection exhaustion
• Application connection pooling changes: Existing connection pools may need reconfiguration for Aurora's scaling behavior
• Monitoring migration: CloudWatch metrics differ from traditional PostgreSQL monitoring tools
• Backup strategy updates: Aurora's continuous backups replace traditional pg_dump workflows

Real migration timeline: Took us somewhere between 4 and 6 months - lost count after the third rollback attempt. Actually moving the data took like 2 weeks, but figuring out all the operational bullshit took forever. We spent at least a month just trying to get CloudWatch alerts to not be completely fucking useless, and another month debugging connection pooling issues that only happened in production.

MongoDB Atlas: The Schema-Flexible Middle Ground

From SQL to MongoDB: Easier than DynamoDB because you can initially replicate table structures as MongoDB collections. The migration path allows incremental denormalization over time.

Common migration pattern:

// Initial migration: Direct table to collection mapping
// users table → users collection
{
  _id: ObjectId("..."),
  id: 12345,
  name: "John Doe",
  email: "john@example.com"
}

// orders table → orders collection  
{
  _id: ObjectId("..."),
  order_id: 67890,
  user_id: 12345,  // Still using foreign key patterns
  total: 149.99
}

// Optimized after migration: Embedded documents
{
  _id: ObjectId("..."),
  user: {
    id: 12345,
    name: "John Doe",
    email: "john@example.com"
  },
  orders: [
    {
      order_id: 67890,
      total: 149.99,
      items: [...]  // Denormalized for performance
    }
  ]
}

The aggregation pipeline learning curve: SQL developers typically struggle with MongoDB's aggregation syntax. Complex joins become multi-stage pipelines that are harder to debug and optimize.

Sharding gotchas: MongoDB's auto-sharding sounds great until you pick the wrong shard key. Companies often discover sharding problems 6-12 months after migration when data growth creates hot shards. Fixing a bad shard key requires a complete data migration.

Cassandra: The Linear Scaling Promise

Migration complexity: Cassandra requires the most fundamental rethinking of data access patterns. Every query must be designed around partition keys and clustering columns.

Time-series migration success story: A IoT company migrated from PostgreSQL to Cassandra for sensor data storage. The PostgreSQL database couldn't handle 100k writes per second; Cassandra scaled to 1M writes per second linearly by adding nodes.

The data modeling nightmare: Cassandra requires creating multiple tables for different query patterns. The same data is duplicated across tables optimized for specific access patterns.

-- Single PostgreSQL table
CREATE TABLE sensor_data (
  sensor_id UUID,
  timestamp TIMESTAMP,
  temperature FLOAT,
  location TEXT
);

-- Multiple Cassandra tables for different queries
CREATE TABLE sensor_by_id (
  sensor_id UUID,
  timestamp TIMESTAMP,
  temperature FLOAT,
  location TEXT,
  PRIMARY KEY (sensor_id, timestamp)
);

CREATE TABLE sensor_by_location (
  location TEXT,
  timestamp TIMESTAMP,
  sensor_id UUID,
  temperature FLOAT,
  PRIMARY KEY (location, timestamp)
);

Migration timeline: Took way too long - felt like forever. Maybe 15 months? Could've been 18? Hard to track when you're constantly fighting fires. I think we burned at least 4 months just figuring out the data modeling because every goddamn query needs its own table in Cassandra. Then we spent several more months debugging compaction issues that would randomly destroy performance in the middle of the night. Good times.

The Reverse Migrations: When "Modern" Databases Fail

DynamoDB back to PostgreSQL: Several high-profile companies migrated back from DynamoDB when their applications grew beyond simple key-value patterns. The lack of complex queries and joins eventually outweighed the scaling benefits.

Segment's migration: Segment moved their user data from MongoDB to PostgreSQL after hitting scalability and consistency issues. They spent 18 months building tools to migrate 30TB of data while maintaining zero downtime.

The common pattern: Companies migrate to NoSQL for theoretical scaling benefits, then migrate back to SQL when they need complex analytics, reporting, or data consistency guarantees.

Migration Decision Framework

Migrate TO DynamoDB if:

• Your application is read/write heavy with simple query patterns
• Traffic is unpredictable or spiky
• You can redesign your data model for single-table patterns
• Operational simplicity matters more than query flexibility

Migrate TO Aurora Serverless if:

• You need SQL compatibility with managed infrastructure
• Your traffic has predictable patterns with occasional spikes
• You want better performance than standard RDS
• Your team already knows PostgreSQL/MySQL

Migrate TO MongoDB Atlas if:

• Your data structure changes frequently
• You need flexible schemas for rapid development
• Document-based queries match your application patterns
• You can tolerate eventual consistency

Migrate TO Cassandra if:

• You need massive write throughput (100k+ ops/sec)
• Linear scaling is more important than query flexibility
• You have time-series or append-only data patterns
• You can hire/train distributed systems expertise

Stay with traditional PostgreSQL/MySQL if:

• Your current database meets performance requirements
• Complex queries and joins are central to your application
• Your team is productive with existing tools
• Migration costs outweigh the potential benefits

Hidden Migration Costs

The technical migration is often the smallest cost. Real migration expenses include:

Engineering time: At least a year of senior developer time, probably more when you count all the "quick fixes" that turned into multi-week projects
Training costs: Blew around $25k on MongoDB training and certification - half the team still couldn't write decent aggregation pipelines
Consultant fees: Database migration specialists charge something like $300-400/hour and bill you for reading documentation
Dual-running period: Ran both systems for maybe 4 months while everyone made excuses about why we couldn't cut over yet
Rollback planning: Built comprehensive rollback procedures we never used but management insisted on having "just in case"
Monitoring changes: Learning new monitoring tools while your production site is having issues is basically hell
Third-party integrations: Every single analytics, backup, and monitoring tool needed updates - and they all failed in creative ways

The largest cost is often the opportunity cost - features not built while the team focuses on migration.

Understanding these migration realities helps inform the initial choice. But even with perfect information, the "right" database depends heavily on your specific application patterns and requirements.