Do I need to self-host PostgreSQL to get full control over tuning?

Not necessarily.

You can get a lot of tuning control on managed PostgreSQL services, but self-hosting gives you the most complete control. The real question is how much control you need versus how much operational work you want to take on.

Managed PostgreSQL: usually enough control for most teams

With services like AWS RDS/Aurora, Cloud SQL, Azure Database for PostgreSQL, or Supabase/Neon-style offerings, you can often tune:

• shared_buffers
• work_mem
• maintenance_work_mem
• effective_cache_size
• max_connections
• autovacuum settings
• WAL/checkpoint behavior
• some planner and logging settings
• storage/instance sizing

This is enough for many workloads.

Self-hosting: maximum control

If you self-host, you can tune everything, including:

• OS-level settings
• filesystem and disk layout
• kernel parameters
• CPU pinning / NUMA considerations
• custom extensions and versions
• replica topology
• backup/replication architecture
• version compilation flags, if you really want to go that far

This matters if you need:

• very specific performance characteristics
• unusual extension support
• tight cost optimization at scale
• on-prem requirements
• custom storage or network setup
• full access to logs/config/infra behavior

Tradeoff

Self-hosting is not required just to “tune PostgreSQL.”
It’s required only if you need deep infrastructure-level control beyond what a managed service exposes.

Rule of thumb

• Start managed if you want speed, reliability, and moderate tuning control.
• Self-host if you have a strong reason and the operational maturity to handle:
  • backups
  • failover
  • upgrades
  • monitoring
  • security patching
  • performance troubleshooting

If you want, I can also give you a checklist of PostgreSQL settings that managed providers usually expose vs hide, so you can judge whether managed is enough for your use case.