Almost every infrastructure decision I endorse or regret
Startup infrastructure choices—databases, cloud services, CI/CD, monitoring—are portrayed as make‑or‑break decisions that quickly accumulate into a surprising amount of cost and complexity. Commenters debate shared vs per‑service databases, managed offerings like RDS vs self‑hosted on colo or bare metal, the value and expense of tools such as Kubernetes, Datadog, PagerDuty, and Terraform Cloud, and when it actually pays to hire specialists like DBAs. A recurring theme is the trade‑off between moving fast with managed, cloud‑native stacks and retaining simplicity, control, and long‑term cost efficiency through simpler architectures and in‑house expertise.
Database ownership & schema design
- Strong disagreement over “startups can’t afford a DBA.” Many argue one specialist or short‑term consultant is cheaper than repeated mistakes by DBA‑less teams; others say DB expertise can be spread across engineers.
- “Kitchen‑sink” shared databases are widely seen as a recurring source of tech debt and cross‑team coupling. Critics say one bad application can degrade performance for all; defenders note shared data is inevitable at scale but should be centrally governed.
- Splitting into many app‑owned databases localizes problems but multiplies instances to monitor and tune. Some say this works well with team ownership; others say it overwhelms a central DB team.
- Debate on DB governance: some advocate strict gating of schema changes by a DB team; others warn this becomes a bottleneck or useless rubber stamp.
- Discussions on UUID vs integer primary keys: int PKs usually win on performance and index locality; newer UUID variants (e.g., time‑sortable) partly address this.
Managed databases vs self‑hosted
- Many endorse RDS/Aurora for small teams: backups, failover, and upgrades are “outsourced risk.”
- Others call RDS pricing “deranged” at larger scales; several examples where RDS costs could fund DBAs, on‑prem hardware, and colo with money to spare.
- Some recommend re‑evaluating RDS once bills reach “full‑time engineer” levels, or moving high‑load workloads to bare metal or cheaper providers.
- Counterpoint: by the time you hit huge RDS spend, migration risk and organizational inertia often keep you on managed services.
Tooling choices: monitoring, on‑call, workflow
- Datadog gets praise for breadth and UX but heavy criticism for opaque, easy‑to‑explode billing. Some suggest open‑source stacks (Prometheus/Grafana/Loki) or cost‑control layers; others say most companies won’t staff that.
- PagerDuty is often seen as overpriced; OpsGenie and newer on‑call tools are cited as cheaper alternatives.
- Jira vs Linear: Jira is viewed as flexible but easily abused into misery; Linear praised for speed and UX but lacks features like custom fields. Some prefer staying inside GitHub/GitLab.
Kubernetes, Terraform, and infra complexity
- Many feel the stack described (EKS, Flux, Karpenter, etc.) is overkill for a startup and creates an “alphabet soup” of dependencies.
- Others argue managed Kubernetes is reasonable once you have multiple teams and services, but EC2+ASG or ECS/Fargate are simpler for many cases.
- Terraform Cloud is widely criticized on price and rough edges; several report moving to self‑hosted runners or competitors.
Cloud providers and lock‑in
- AWS is praised for breadth, IAM integration, and support; GCP for simpler concepts and Cloud Run ergonomics; Azure UI is widely disliked.
- Concerns around data egress costs and proprietary services (Aurora, RDS, etc.) locking companies into expensive cloud footprints.
- Some larger orgs and startups report moving back to colo/on‑prem for cost and “keep the know‑how” reasons, especially at steady large scale.