Aamir Haroon
Senior Cloud Architect I
The Database Wizard 🧙
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)
AWS Certified Data Engineer - Associate
AWS (last renewed/obtained: Jul 31, 2025)
Google Cloud Professional Cloud Database Engineer
Google (last renewed/obtained: Oct 23, 2025)
What my customers say
very fast responses
sama.com · May 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
Customer Playbooks
years in databases
/5 rating
Reviews
Certifications
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.