☁️SQL hosting
A database is a service dependency
You rarely “host SQL” as files on disk, production means managed RDS-style services or clusters you operate: networking, storage growth, HA failover, patching, backups, and extension allowlists. The relational model is unchanged; the operational contract and hard limits are not.
⚖️Where responsibility lands
Vendor vs team, document both.
| Option | Trade-off |
|---|---|
| Managed (RDS, Cloud SQL, Azure SQL) | Less patching and storage babysitting; some knobs hidden or gated; still your queries and IAM. |
| Self-managed on VMs / Kubernetes | Full control of versions and extensions; you own backup validation, failover drills, and on-call. |
Connectivity check (PostgreSQL)
SELECT inet_server_addr() AS db_host,
current_database() AS db,
version() AS v;| db_host | db | v |
|---|---|---|
| 10.12.3.4 | biotech_app | PostgreSQL 16.3 on x86_64-pc-linux-gnu |
Black-box mindset
- Assuming superuser or unsafe extensions exist in managed tiers.
- Disk full surprises because WAL or PITR retention was never sized.
- Cross-region clients ignoring RTT in every query path.
SLAs, limits, runbooks
- Read vendor ceilings (connections, IOPS, extension lists) before architecture sign-off.
- Automate storage and log retention alerts; keep IaC next to application IaC.
- Private networking, least-privilege DB users, and documented replica endpoints.
Maintenance windows
Minor version upgrades and parameter group changes still cause restarts or brief failovers, treat the provider’s schedule as part of your availability story, not background noise.
TL;DR
Managed SQL (RDS, Cloud SQL, Azure SQL, PlanetScale, etc.) runs the engine for you: provisioning, patching, backups, failover, read replicas, and sometimes pooling. You still own schema design, query performance, migrations, and security (IAM, VPC, encryption). SLAs cover uptime of the service, not that every query is fast.