Aamir Haroon
- EN
- UR
- SD
- HI
- PA
Senior Cloud Architect I
The Database Wizard 🧙
United States
Databases lie. They say "performance problem" when they mean "configuration problem." They say "slow query" when they mean "nobody tuned autovacuum since launch." I've been catching them in the act for 20 years.
Started as an Oracle DBA. Now I work on RDS, Aurora, and Cloud SQL — same underlying honesty problems, different cloud logos.
When a tool doesn't exist, I build it. When things break at the worst moment, I stay calm.
Off the clock: building an AI tutor for Islamic schools, helping Texas homeowners fight their property tax bills. I seem to specialize in problems that look unsolvable until you actually look at them.
- RDS
- Cloud SQL
- Aurora
- Oracle Database
- Cost Optimization
- Data Engineering
My Certifications
AWS Black Belt Pilot, Database
AWS (last renewed/obtained: Aug 7, 2023)
Expires Aug 7, 2049
AWS Certified Data Engineer - Associate
AWS (last renewed/obtained: Jul 31, 2025)
Expires Jul 31, 2028
Google Cloud Professional Cloud Database Engineer
Google (last renewed/obtained: Oct 23, 2025)
Expires Oct 23, 2027
What my customers say
Very helpful guidance which helped me resolve the issue.
roscommonanalytics.com · Aug 2026
What I'm writing
When to Use AlloyDB Instead of Cloud SQL for PostgreSQL
A data-backed comparison featuring performance benchmarks, pricing breakpoints, and architectural trade-offs.
Improve Reliability in PostgreSQL 17: Leveraging Logical Replication Failover
PostgreSQL 17 introduced the sync_replication_slot parameter, a game-changing feature to maintain logical replication…
What I've open-sourced
Come work with me
Open roles I'd love to refer you for
years in databases
customers supported
customer issues solved
customer satisfaction
How I help
Performance, replication, connectivity, locking, and those mysterious production issues.
RDS, Aurora, Cloud SQL, PostgreSQL, Oracle, and database architectures that can survive real-world workloads.
Move databases between platforms and clouds without turning migration day into incident day.
Find the bottlenecks, reduce unnecessary cost, and make databases behave the way they should.
When the right tool doesn’t exist, I build it.
Customer Playbooks
Frequently asked
questions
RDS or Aurora — which should I pick?
Aurora, if you need high availability, can't afford downtime, and your application can batch commits. It fails over in under 30 seconds, and scales read instantly. RDS if your workload is predictable, your commit rate is high, or you just want simpler pricing.
The mistake I see most: people pay for Aurora when RDS would do the job, or they cheap out on RDS when they actually need the failover. Get the sizing right first, then pick the engine.
AlloyDB or Cloud SQL for PostgreSQL?
Cloud SQL for most workloads is simpler, cheaper, and well-understood. AlloyDB when you're hitting Cloud SQL's ceiling: analytical queries on a transactional database, or when you need columnar acceleration without moving to BigQuery. I wrote a full breakdown with benchmarks if you want the longer answer. https://www.doit.com/blog/when-to-use-alloydb-instead-of-cloud-sql-for-postgresql
What's the most common database mistake you see?
Leaving autovacuum on default settings and wondering why the database slows down at scale. PostgreSQL's defaults assume a small table. A 10-million-row table on RDS needs to accumulate 1,000,050 dead rows before autovacuum even fires. I built pg-vacuum-advisor because I was diagnosing this same problem over and over.
When does autovacuum actually need tuning?
As soon as your tables cross ~1 million rows. The default scale_factor means autovacuum waits for a percentage of the table to be dead before it acts — fine for small tables, a disaster for
large ones. The fix is per-table settings via ALTER TABLE. It's not glamorous, but it's one of the highest-ROI things you can do for a busy PostgreSQL database.
What’s your approach when production is already on fire?
The first thing is to stop the bleeding. I'm not going to sit there theorizing about the root cause while the site is down. Kill the runaway query, fail over, roll back the change that kicked it off, shed some load, whatever gets you breathing again fastest.
Once things are stable, I actually dig in: wait events, locks, slow query logs, replication lag, and what changed in the last few hours, because it's almost always something that changed.
I'll keep you posted the whole way through in plain English, since the worst thing during an incident is not hearing anything. And when it's done, I write up what really happened and the one guardrail that stops it from biting you again. A fix that falls apart on the next deploy isn't a fix.