From DBA to Tech Lead: Wang Le on Database Migration, Platform Engineering, and Open Source Growth

In this interview, Wang Le, database team lead at vivo, reflects on his career trajectory from traditional DBA to technical manager, covering three major industry waves: the de-IOE movement, domestic database substitution, and the emerging AI transformation.

Cognitive Shift: From Relying on Database Capabilities to Using Them Well

Wang identifies the biggest cognitive iteration as moving from "relying on database capabilities" to "using database capabilities well." Early de-IOE efforts focused on replacing commercial databases with open-source and distributed architectures to solve cost and scalability. Teams often treated database features as "silver bullets," depending on hidden parameters for tuning. With development experience, he realized well-designed systems don't need "black magic" rescues. The domestic substitution phase shifted focus to autonomy and ecosystem adaptation — no perfect database exists, only the most suitable architecture for the business. The AI wave will change how databases are used and managed, requiring DBAs to expand into platform development, architecture design, and technical management.

Domestic Database Replacement: New Challenges vs. Reusable Experience

Wang notes organizational cost now exceeds technical cost, with talent shortage as the biggest bottleneck. Open-source databases (MySQL) had mature ecosystems and abundant talent; domestic databases have relatively closed ecosystems and scarce deep expertise. He recounts an ARM architecture adaptation issue at Tencent that required 10+ experts from Tencent and Huawei to root-cause, illustrating high human-cost investment.

Reusable experience: migrations must support canary releases and rollback capability. Experience to discard: avoid single-vendor lock-in. Database selection must follow the principle of "can go up, can come down" — portable and reversible.

Large-Scale Migration: Failure Points and Reusable Process

The most failure-prone stage is not data sync but post-migration performance issues. Many performance problems only trigger under specific business scenarios, invisible during benchmark testing. A reusable migration process requires three pillars: canary-capable, observable, rollback-ready. Assessment must cover compatibility and data volume. Rehearsal needs full-scale dry runs with comprehensive monitoring for performance and data consistency. Cutover uses gradual traffic shifting — verify small traffic first. Rollback plans must be pre-tested.

Platform Engineering: Standardization → Automation → Platformization

Wang's evolution: manual ops → self-taught Python → built automated deployment platform and adaptive baseline monitoring → proposed the "standardization → automation → platformization" evolution path.

On AI/AIOps integration: platform capability is the foundation, expert experience is the soul, AI is the finishing touch. AI needs real production data via MCP/tools; without automated interfaces and standardized data, AI cannot act. Vertical expert experience must be structured into knowledge bases/graphs for AI — this differentiates vertical AI from general models. Teams without automation foundations should not jump straight to AI; poor data quality and incomplete automation cause misjudgments that increase ops burden. First, complete platformization.

On "platform and production as two separate skins": root cause is platforms not solving real ops pain points. If platforms deliver business value, improve efficiency, and reduce risk, DBAs will adopt them. Actions: (1) Requirements — dig for true needs (e.g., devs asking for binlog parsing may actually need a DB change management system to reduce change risk). (2) Design — prioritize UX and usability. (3) Rollout — canary with urgent-need users first, iterate quickly, then expand; make users feel the platform is a helper, not a burden.

Open Source Contribution: gh-ost Bug Fixes and Community Engagement

At Tencent Financial (Caifutong), gh-ost executed tens of millions of online schema changes yearly. A data loss incident in this payment-critical environment (where data consistency is the lifeline) was a massive shock. Even extremely low-probability bugs get amplified at scale. Several consistency bugs only triggered in extreme edge cases. High execution frequency + strict consistency requirements drove Wang to study gh-ost source code. Without understanding internals, the tool is a "time bomb." Research was business-driven, not academic — he had annual "study MySQL source code" goals but lacked motivation until business needs forced deep dives.

Feasible entry path for ops engineers: start with testing and bug reproduction. When tools behave unexpectedly or miss requirements, write targeted tests, clearly describe issues with reproduction steps, environment config, logs — submit issues. This is more valuable than direct bug fixes. For recurring issues, check existing issues; if none, read source, attempt fix, submit PR. Biggest barrier isn't technical — it's lack of immediate positive feedback. Ops work is high-pressure; evenings spent on unfamiliar codebases, waiting for reviews, facing rejections causes frustration. Two rejected PRs and many quit. PR rejections and issue closures are normal. In the AI era, the challenge shifts: too many PRs — how to make contributions more valuable.

Philosophy: "Plant Causes Diligently, Do the Hard Right Things"

Vivo's "benfen" culture ("do the right thing, do things right") aligns with Tencent's "do the hard right things" (user-value oriented). Two layers: (1) persist in doing the right thing — long-term value for business/users; (2) do things right — overcome difficulties.

Example: returning to vivo, Wang prioritized building database HA capability and moving cloud databases to self-managed for multi-cloud unity and autonomy. Short-term: huge team challenge, increased workload. Long-term: autonomous HA enables more stable operations, lasting business value. Hard part: securing organizational support. Key: find alignment between platform work and business value. Not platformization for its own sake — solve real business needs. Some needs are correlational, not direct; find the intersection. E.g., business postmortems demand higher stability (4-5 nines availability) → translates to platform needs: auto-failover, auto-cluster-management. For hard-right projects, locate the business-value intersection, deliver via technology — easier to gain support.

Three Practical Tips for DBAs Expanding Their Scope

Continuous learning. Tech iterates fast: traditional DB → open-source → NoSQL → distributed → domestic → vector DBs. AI accelerates this. Maintain a learning mindset.

Step out of comfort zone. Experienced DBAs: don't rest on past experience or single-DB mastery. Consciously take on out-of-scope work — learn more DB types, different tech stacks, coding (especially AI-assisted coding). Comfort zone expands when you step out.

Plant causes diligently; results follow naturally. Expanding capabilities isn't overnight. Short-term may show no visible effect — easiest time to waver. Trust long-termism. Every extra language learned, DB touched, hard problem solved is planting a cause. Don't quit for lack of short-term feedback; change arrives at its moment. Persist in doing the right thing.