Database Optimization and Azure MySQL Migration for a High-Volume Messaging Platform

Key Metrics

Industry	Enterprise Communications / High-Volume SMS & Voice Messaging
Challenge	Single MySQL instance serving both transactional and analytical workloads, slow reporting queries, sparse 25M-row contact model, aging MySQL 5.7
Solution	Query and index optimization, JSON-based contact restructure, SingleStore POC, Azure migration, MySQL 8.x upgrade
Tech Stack	MySQL, Azure Database for MySQL, SolarWinds DPA
Results	Minutes-to-seconds reporting queries, sub-100ms contact lookups, 100x faster SingleStore benchmark, ISO 9001-compliant cloud infrastructure

TrueDialog runs one of the more demanding data environments in enterprise communications: a high-volume SMS and voice messaging platform where real-time performance isn’t a preference, it’s a product requirement. For years, that platform ran on a self-hosted MySQL database that was doing double duty, handling live transactional messaging while also carrying the weight of increasingly heavy analytical reporting. The combination was taking its toll.

Data-Sleek engaged as TrueDialog’s database administration partner across a multi-year relationship. The work spanned query optimization, a contact data re-architecture, a proof-of-concept evaluation of SingleStore as an alternative engine, a full migration from on-premise infrastructure to Azure Database for MySQL, and a version upgrade from MySQL 5.7 to 8.x. At every stage, the goal was the same: measurable performance improvement without disrupting a live platform that customers depended on daily.

The Challenges: A Database Carrying More Than It Was Built For

When Data-Sleek first engaged, TrueDialog’s database was showing familiar signs of a system that had grown faster than its architecture. The core issue was consolidation: a single MySQL instance was serving both real-time messaging operations and analytical reporting, and those two workloads have competing demands. Transactional queries need speed and consistency. Analytical queries need to scan large volumes of data. Running both on the same system meant each was compromising the other.

The reporting problem was most visible. Several critical queries running against large tables, including action, contact, and campaign_session, each holding tens of millions of rows, were taking minutes to return. That delay wasn’t just an inconvenience; it was slowing down the operational decisions that TrueDialog’s teams needed to make in real time.

The contact attribute data structure compounded the problem. With roughly 25 million rows stored across a wide, sparse relational model, attribute lookups and filtered searches were expensive by design.

Beyond performance, infrastructure risks were accumulating. The MySQL engine was running on version 5.7, approaching end of support, and the on-premise hosting model was limiting the team’s ability to scale, maintain compliance posture, and reduce operational overhead.

Strategic Objectives

TrueDialog needed performance gains, but they also needed discipline about how to get there. The risk of disrupting a live, high-volume messaging platform meant that every change had to be validated before it touched production. The objectives Data-Sleek worked toward reflected that constraint: accelerate reporting queries without re-platforming, evaluate whether a specialized engine could change the calculus, restructure contact data to support faster lookups, upgrade MySQL to a supported version, and move the database from on-premise infrastructure to a managed cloud environment.

None of these were treated as independent workstreams. Each decision informed the next.

The Solution: A Phased Approach That Fixed Before It Replaced

Starting with what was already there

Before recommending any architectural change, Data-Sleek diagnosed the platform’s most expensive queries and identified where targeted index work could recover the most ground. Adding composite indexes to the action and campaign_session tables, targeting the specific column combinations those reporting queries were filtering on, cut execution times on key queries from minutes to seconds. The infrastructure hadn’t changed. The data model hadn’t changed. The indexes changed, and the impact was immediate.

Re-architecting the contact attribute model

TrueDialog’s contact attribute structure was storing roughly 25 million rows across a wide, sparse relational model that made attribute lookups and filtered searches expensive. Data-Sleek restructured that into a consolidated JSON format, collapsing attributes into a single field per contact record. Attribute lookups and LIKE searches across those 25 million records, including joins back to the contact table, returned in under 100 milliseconds.

Evaluating SingleStore through a real proof-of-concept

One of the persistent questions in the engagement was whether MySQL, even well-optimized, was the right engine for TrueDialog’s mixed workload long-term. Rather than evaluate it theoretically, Data-Sleek stood up a SingleStore environment and loaded it with production-representative data from TrueDialog’s chat and contact tables. Target queries ran up to 100x faster in SingleStore than in MySQL on the same workloads.

The POC gave TrueDialog a data-backed architecture decision rather than a vendor pitch. They weighed a full engine migration against an optimized MySQL-on-Azure path on actual evidence and chose to stay on MySQL.

Migrating to Azure

The migration to Azure Database for MySQL proceeded as a structured, validated project. Data-Sleek used TrueDialog’s existing on-premise primary instance as the source, established a managed Azure instance as the target, and set up replication between them. Before any production cutover, the team completed a full validation cycle: backup, restore to the managed instance, replication setup and validation, and UAT testing with TrueDialog’s engineering team.

Applications were repointed to the Azure managed instance with minimal downtime. Database names, tables, and columns stayed the same throughout, a deliberate choice to reduce application-layer risk during cutover. The outcome was infrastructure that was more resilient, easier to maintain, and compliant with ISO 9001 requirements.

Upgrading MySQL and sustaining the environment

With 5.7 approaching end of support, Data-Sleek built and validated a read replica to test the upgrade to 8.0/8.4 against production-representative data before committing any changes to the live system. Ongoing, Data-Sleek continued as TrueDialog’s DBA partner, handling performance monitoring through SolarWinds DPA, building an archiving framework to manage retention on the platform’s largest tables, and supporting the engineering team through continued platform growth.

Key Deliverables

Each workstream produced a concrete, documented output.

• Query and Index Optimization: Composite indexes on the platform’s largest tables reduced key reporting query times from minutes to seconds.
• Contact Attribute Restructure: A JSON-based attribute model delivering sub-100ms lookups across roughly 25 million records.
• SingleStore Proof-of-Concept: A benchmarked evaluation showing up to 100x faster performance on target workloads, giving TrueDialog an objective basis for its architecture decision.
• Azure Migration: Successful migration of the self-hosted MySQL database to Azure Database for MySQL.
• MySQL Version Upgrade: A tested 5.7 to 8.x upgrade path validated against a production replica before any production change.
• Ongoing DBA Support: Continued database administration, performance monitoring, and archiving support beyond the project milestones.

The Results: Measurable Outcomes Across Every Workstream

The optimization, migration, and POC work each produced distinct, measurable outcomes.

• Query Performance: Critical reporting and search queries reduced from minutes to seconds. Contact attribute lookups returned in under 100ms across roughly 25 million rows.
• Modernized Infrastructure: The database moved from self-hosted on-premise to managed Azure cloud, improving reliability and compliance posture (ISO 9001).
• Future-Proofed Engine: A clear, tested upgrade path off an end-of-life MySQL 5.7 version onto a supported release, validated against a production replica before cutover.
• Informed Architecture Decisions: A real benchmark, not a vendor pitch, let TrueDialog weigh SingleStore against an optimized MySQL-on-Azure path on the merits. TrueDialog retained their MySQL stack with confidence.
• Sustained Partnership: A multi-year DBA relationship supporting TrueDialog through continued platform growth, including industry recognition for their messaging platform.

Lessons Learned

This engagement reinforced a few principles that apply broadly to database administration and data architecture work.

Optimization should come before migration. The index changes on TrueDialog’s largest tables recovered significant performance without touching the infrastructure at all.

Proofs-of-concept are worth doing properly. The SingleStore evaluation only had value because it used real data, real queries, and a real environment.

The right tool isn’t always the newest tool. An optimized MySQL-on-Azure stack met TrueDialog’s needs without forcing a disruptive engine change.

Validated upgrade paths reduce cutover risk. Testing the MySQL 5.7 to 8.x upgrade against a replica meant the first time the new version ran against production data wasn’t when production was live on it.

Working With a Database Under Pressure

If your platform is carrying both transactional and analytical workloads on aging infrastructure, there is usually significant performance to recover before you need to re-platform. Book a free consultation to talk through your database environment.