Database Administrator

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.

Work arrangement
No