Senior Database Reliability Engineer, Trumid

• Five or more years running production PostgreSQL at meaningful scale — ideally on RDS or Aurora — with depth in the internals: replication, WAL mechanics, MVCC and vacuum behavior, query planning and performance
• You’ve owned the full lifecycle of data somewhere, not just the query path: retention, backup and restore, access control, and security posture
• Disaster-recovery experience you can talk through concretely — failovers you designed, drills you ran, and what they changed
• Infrastructure fluency: infrastructure-as-code (Terraform or similar), scripting (Python, bash, SQL), Linux, and cloud storage/IOPS characteristics
• An SRE sensibility: SLOs, blameless postmortems, and a preference for rehearsed over improvised
• Clear writing — you leave runbooks and decision records behind you

Desirable

• This role owns data resilience and continuity, and the scope test is simple: if losing it loses data, or makes data unavailable, it’s yours
• The job exists so that data-layer failure modes — storage contention, replica lag, region loss — are found and retired in drills, not discovered in production
• Our reliability doctrine is to assume failure and concentrate statefulness into a small core of systems proven against specific failure modes
• Postgres is the heart of that core: everything around it gets to be disruptible because the data layer is not
• You’d join the databases side of our SRE team, working alongside deep Postgres expertise. Some of what you’d walk into:
• A production RDS fleet backing a live trading venue, with performance work that goes deep: we’ve characterized WAL-write contention under concurrent commits down to the fsync level, and are weighing group-commit tuning, dedicated log volumes, and storage-class changes against actual measurements
• Disaster recovery as an engineering discipline: automated cross-region failover with promotion measured in minutes, and restore paths (snapshot, point-in-time, logical) validated by timed, documented drills on a fixed cadence
• Database observability and AI-assisted tooling: engine performance telemetry exported into Prometheus and Grafana, modular database health-check skills, and an automated reviewer for schema-migration PRs
• Own the durability, recoverability, and performance of the Postgres/RDS fleet across every environment: replication, failover, backup and restore, and storage behavior under load
• Make recovery provable: restore-tested coverage of every production database, timed failover drills, and measured RPO/RTO per tier — evidence, not assertion
• Own the data lifecycle end to end: retention and cleanup policies that preserve recoverability, access control at the data layer, encryption posture, and knowing where sensitive data lives
• Hunt performance pathologies at the engine level: lock contention, WAL throughput, replica lag, bloat, index hygiene, write amplification
• Build database observability with the team, and extend our AI-assisted operations tooling (health-check skills, migration PR review)