JOB DESCRIPTION
Database Administrator — Trading Portals
Owning the data tier behind One Portal and the client, IB and admin portals already in production.
Job title:- Database Administrator (Senior / Lead)
Department:- Technology:- Portals & Platform
Location / working model:- Remote
Experience required:- 6+ years MySQL / MariaDB in production
1. Purpose of the role
Our client-facing and administrative portals are the system of record for client onboarding, funding, and introducing-broker (IB) rebates. The database schema has grown alongside the product rather than under a dedicated data owner. This role establishes that ownership.
Four specific pressures make the hire necessary now:
- The client and admin applications share one operational database whose migration history now exceeds 165 change files, several of which rewrite client identity and tenancy keys on live tables.
- The One Portal programme consolidates the client portal, the IB portal and a new in-house CRM onto a single multi-entity data model, and moves reporting, dashboard and AI-assistant reads onto read replicas and redacted views.
- Funding currently dual-writes to external instant-funding and payment-provider databases while the portal-side ledger becomes authoritative. The cutover requires reconciliation that someone owns end to end.
- No one currently rehearses database restores, owns index and capacity strategy, or reviews schema changes before they reach production. Because the data includes client money movement and KYC records, this is a compliance exposure as well as an engineering one.
2. Key responsibilities
2.1 Availability and recovery
- Own backup, point-in-time recovery and retention across every production data store, proven by scheduled restore rehearsals with measured recovery point and recovery time objectives.
- Own replication topology, failover behaviour and replica-lag budgets for multi-availability-zone MariaDB and its read replicas.
- Write and maintain runbooks for the failure modes specific to this environment: a stalled migration, a runaway reporting query, or a replica falling behind during month-end IB rebate runs.
2.2 Schema change and release control
- Review every database migration before it is merged — locking behaviour, index coverage, nullability, foreign keys and backfill cost against real production row counts.
- Enforce the expand → backfill → switch → contract pattern for breaking changes, using online schema-change tooling where table size requires it.
- Rehearse the high-risk CRM and identity migration chain on a production-shaped copy of the data, retaining reconciliation evidence for each rehearsal.
- Own the maintenance calendar against the FX trading week: structural change is released at weekend market close, not mid-week.
2.3 Performance and capacity
- Run slow-query review as a standing routine and return fixes to the application teams with the query plan attached.
- Set index, partitioning and archival strategy for the large funding, trading-account and audit tables, including retention of records required by compliance but not queried operationally.
- Tune connection pooling, buffer pools and server parameters across application, queue-worker and reporting workloads.
- Forecast capacity and review instance sizing and cost for managed database and cache services.
2.4 Security, access and standards
- Implement least-privilege database roles: separate credentials per application, per queue worker and per reporting consumer, with SELECT-only redacted views behind reporting and AI read paths.
- Maintain encryption at rest and in transit, credential rotation, and the removal of shared logins and ad-hoc production access.
- Maintain audit trails and data-retention controls that withstand regulator and external-auditor scrutiny of KYC and money-movement records.
- Define and publish naming, character-set and data-modelling standards, and keep an inventory of databases, owners and data classification.
3. Candidate requirements
3.1 Essential
- Six or more years administering MySQL or MariaDB in production, including at least one environment carrying financial or otherwise regulated transaction data.
- Hands-on ownership of replication, failover and point-in-time recovery, with the ability to talk through a restore they personally performed under time pressure.
- Strong query and schema optimisation: execution-plan analysis, composite index design, and the judgement to rewrite a query rather than add another index.
- Delivered zero-downtime schema changes on large tables using gh-ost, pt-online-schema-change or native online DDL.
- Able to review an ORM-generated migration and the SQL it produces. Laravel or other PHP framework experience is an advantage; unfamiliarity with PHP is not a blocker.
- Practical AWS RDS or Aurora experience: parameter groups, multi-AZ, replicas, snapshots and CloudWatch metrics.
- Monitoring and diagnosis using slow-query logs, performance_schema, and a tool such as Percona Monitoring and Management.
- Automation scripting in Bash plus Python or PHP, with database changes version-controlled and peer-reviewed like application code.
- Clear written communication — this role publishes standards and runbooks that developers are expected to follow.
3.2 Desirable
- Retail FX, CFD or brokerage industry background, or familiarity with MT4/MT5 data structures.
- Multi-tenant or multi-entity data modelling, where one client identity is scoped by regulatory entity.
- Data migration from a SaaS CRM such as Salesforce into a self-hosted model, including reconciliation of migrated records.
- Redis, RabbitMQ or Kafka operations alongside a relational estate.
- Infrastructure as code and CI-driven migration rehearsal (Terraform, Ansible or equivalent).
- PostgreSQL or SQL Server, and analytics or data-warehouse replica experience.
- Experience working within PCI DSS, GDPR or financial-regulator audit cycles.