Overview

I was building a bank statement and transaction tracker application for myself over the weekend. Nothing complex—just a way to aggregate transactions from multiple accounts and categorize spending patterns.

The application worked locally. Time to think about deployment.

My default mental model kicked in immediately: EC2 for the application, RDS for PostgreSQL, S3 for storing statement PDFs, Route 53 for DNS. Standard production architecture. The “right” way to deploy.

Then I paused. This is for me. Maybe one other person. Do I really need managed RDS for a database that’ll handle 50 transactions a day?

That question led me down a rabbit hole that changed how I think about infrastructure decisions—not just for personal projects, but for the dev environments we run at work.

---

Problem Statement

We learn system design through the lens of scale. How do you handle millions of users? How do you ensure 99.99% uptime? How do you architect for growth?

But there’s a huge gap between “architecting for scale” and “architecting for your current reality.”

For a personal application with 1-2 users, do you need:

• Managed RDS with automatic backups and Multi-AZ deployment?
• Separate S3 buckets with lifecycle policies?
• Load balancers and auto-scaling groups?

Obviously not. But we default to these patterns because they’re what we know, what we’ve been trained to build, what “production” looks like.

Here’s what struck me: if this over-engineering is obvious for a 1-2 user application, what about dev environments at work? Small teams running dedicated RDS instances for each developer during 3-6 month development cycles. Is that actually necessary, or is it just accepted practice?

System design principles should apply at every scale—including the scale of “5 developers iterating on features.”

---

Approach

Let me model two scenarios to illustrate this:

Scenario A: Personal App Deployment (1-2 users)

Application specs:

• Node.js backend
• PostgreSQL database
• Statement PDF storage
• ~50 transactions/day
• ~2 statement uploads/month
• Basic authentication

What I almost built:

• EC2 t3.micro for application
• RDS db.t3.micro for database
• S3 for file storage
• Route 53 for DNS

What actually makes sense:

• Single EC2 t3.micro
• PostgreSQL in Docker with mounted volume
• Local file storage (or S3 if needed later)
• Route 53 for DNS

Scenario B: Dev Environment at Work (5-10 developers)

Team specs:

• 8 developers working on same application
• Each has separate dev environment
• 3-month development cycle for major feature
• Active development 8 hours/day, 5 days/week

Current setup (what I’ve seen at workplaces):

• 8 separate RDS instances (one per developer)
• Each runs 24/7 during development cycle
• Treated as “necessary” for isolated development

Alternative approach:

• Each developer runs PostgreSQL in Docker locally
• Shared staging RDS for integration testing
• Graduate to individual RDS only when testing RDS-specific features

Let’s run the actual numbers for both scenarios.

---

Cost Breakdown: Personal App (1-2 users)

Option A: “Standard” Production Setup

Component	Monthly Cost	Notes
EC2 t3.micro	$7.59	730 hours/month
EBS Volume (8GB)	$0.80	gp3 storage
RDS db.t3.micro	$12.41	730 hours/month
RDS Storage (20GB)	$2.30	gp2, 20GB minimum
S3 Storage (1GB)	$0.02	Standard storage
Route 53 Hosted Zone	$0.50	Per hosted zone
Total	$23.62

Option B: Right-Sized Setup

Component	Monthly Cost	Notes
EC2 t3.micro	$7.59	730 hours/month
EBS Volume (20GB)	$2.00	gp3, app + DB + files
Route 53 Hosted Zone	$0.50	Per hosted zone
Total	$10.09

Savings: $13.53/month (57% cheaper)

For my use case—50 transactions a day, occasional statement uploads—the single EC2 setup handles everything comfortably. Database stays under 500MB. File storage under 1GB.

---

Cost Breakdown: Dev Environments (8 developers, 3 months)

This is where it gets interesting.

Option A: Separate RDS per Developer

Component	Monthly Cost (per dev)	Total (8 devs)
EC2 t3.micro	$7.59	$60.72
EBS Volume (8GB)	$0.80	$6.40
RDS db.t3.micro	$12.41	$99.28
RDS Storage (20GB)	$2.30	$18.40
Monthly Total	$23.10	$184.80
3-Month Cycle	$69.30	$554.40

Option B: Docker DBs + Shared Staging

Component	Monthly Cost (per dev)	Total (8 devs)
EC2 t3.micro	$7.59	$60.72
EBS Volume (12GB)	$1.20	$9.60
Shared Staging RDS	-	$14.71
Staging RDS Storage	-	$2.30
Monthly Total	$8.79	$87.33
3-Month Cycle	$26.37	$261.99

Savings over 3 months: $292.41 (53% cheaper)

But here’s what this doesn’t capture: developer workflow impact.

---

What The Data Actually Shows

Speed: Docker vs RDS

I tested both setups with realistic dev workload:

Operation	Docker (localhost)	RDS (same AZ)
Simple SELECT	1.2ms	2.8ms
Complex JOIN (3 tables)	8.5ms	11.3ms
INSERT (single row)	2.1ms	3.9ms
Transaction (10 ops)	15.2ms	21.7ms
Schema migration	0.8s	1.4s

Docker is consistently faster. Network latency—even within the same AWS availability zone—adds overhead that localhost doesn’t have.

For a developer running tests hundreds of times a day, this compounds.

Flexibility: What You Can Do

Docker setup:

• Wipe database instantly for clean test runs
• Experiment with different PostgreSQL versions
• Test migrations without fear
• Stop/start container in seconds
• Full control over configuration

RDS setup:

• Slower to reset (snapshot restore or manual cleanup)
• Locked to RDS-supported versions
• More careful with migrations (can’t just blow it away)
• Always running (can’t “turn off” between work sessions)
• Limited configuration access

The “Production Parity” Argument

The usual defense for RDS in dev: “It’s closer to production.”

But let’s be honest:

• Production uses Multi-AZ RDS
• Production has read replicas
• Production has different instance types
• Production has different backup/retention policies
• Production has different security groups and network configs

Your dev RDS isn’t production-like. It’s a smaller, cheaper approximation.

You’re already accepting differences. The question is: which differences matter?

If you’re testing application logic, queries, and features—Docker is fine. If you’re testing RDS-specific features (failover, read replicas, automated backups)—then you need RDS.

Most development cycles are the former. We use RDS anyway because it’s “proper.”

---

When Does This Approach Break Down?

I’m not advocating for Docker everywhere. Here’s when you actually need RDS in dev:

Use RDS when:

• Team needs shared database access (multiple devs testing against same data)
• Testing RDS-specific features (Multi-AZ failover, read replicas, automated backups)
• Database size exceeds practical local development (>5GB)
• Staging environment that needs production-like uptime
• Compliance/security requirements mandate managed services

Docker works when:

• Developers work on isolated features with separate data
• Rapid iteration with frequent database resets
• Early-stage development where schema changes constantly
• Cost is a constraint (bootstrapped teams, side projects)
• Testing application logic, not infrastructure behavior

For my personal app? Docker makes sense. It’ll handle 1-2 users comfortably.

For the dev environments at work? We could save $300+ per development cycle per team by defaulting to Docker for individual devs and maintaining one shared staging RDS for integration testing.

---

The Broader Lesson

This exercise reminded me that system design isn’t just about scaling to millions of users. It’s about right-sizing infrastructure for your current context.

Ask these questions at every scale:

• What load am I actually handling?
• What reliability do I actually need?
• What am I optimizing for right now?

For a personal project with 2 users: optimize for cost and simplicity. For a dev environment with 8 developers: optimize for iteration speed and cost. For a production app with 100k users: optimize for reliability and scale.

The principles are the same. The execution should match the context.

I deployed my bank statement tracker on a single EC2 instance with Docker. It costs $10/month. It handles my needs perfectly.

And now I’m looking at our dev infrastructure at work with fresh eyes.