Technical Leadership Best Practices
Database council for cross-team schema changes. Use this list when establishing or auditing data platform leadership.
How to Use This List
- Adopt council cadence before the second team shares one database.
- Score each service quarterly against connection, migration, and review items.
- Publish decisions as ADRs in git, not meeting notes only.
- Pair list with error budget and incident post-mortem actions.
A - Governance
- Database council meets weekly with migration queue. Cross-team conflicts surface early.
- Single schema style guide enforced in CI. Naming, FK policy, RLS patterns documented.
- Schema changes treated as API semver. Breaking changes use expand/contract.
- ADR required for shared-table ownership disputes. Who writes, who migrates.
B - Quality Bar
- Query review standards mandatory above QPS threshold. EXPLAIN evidence in PR.
- Index requests flow through measured approval. No ad hoc production
CREATE INDEX. - pg_stat_statements reviewed weekly. Top ten by total time has owner.
- MVCC training for every new service team. Within 30 days of first deploy.
C - Reliability Partnership
- Tech lead co-owns datastore SLO with SRE. RPO/RTO explicit in status docs.
- On-call runbooks linked from service README. Disk, locks, lag scenarios.
- Post-incident actions tracked to completion. Same sprint as post-mortem.
- Maintenance windows coordinated with product calendar. Blackout dates shared.
D - Cost and Growth
- Storage growth forecast shared with finance monthly. Tie to retention and indexes.
- Replica count justified by read SLO. Not "default 2" without load proof.
- Right-sizing review quarterly. Instance generation and IOPS match working set.
- Retire unused indexes and schemas. idx_scan monitoring with drop policy.
FAQs
How big should database council be?
One delegate per consuming service plus DBA chair; keep under 10 people for decisions.
What if teams resist council?
Tech lead escalates via incident cost and SLO misses; start advisory then mandate after Sev-2.
Does council block delivery?
Goal is parallel-safe migration ordering, not veto power for velocity.
How to handle acquired company schema?
Council adds integration track; separate ADR for merge vs federated databases.
Should tech lead write SQL?
Yes for standards and reviews; delegate deep tuning to staff DBA.
How to measure leadership impact?
Incident frequency, migration failure rate, mean time to approve safe schema change.
What about polyglot persistence?
Council scope clarifies Postgres vs other stores per bounded context.
AI-generated schema in council?
Same review bar; generated DDL is not auto-approved.
Remote-first council tips?
Async migration doc 24h before; live only for conflicts and incidents.
What should I read next?
Related
- Tech Lead Basics on Postgres - correctness/uptime/cost
- Query Review Standards - PR bar
- Governance Basics - org standards
- Working with Engineering Best Practices - stakeholder alignment
- Change Management Best Practices - DDL safety
Stack versions: This page was written for PostgreSQL 18.4 (stable 18, maintenance 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, and PostGIS 3.5+.