--- name: tidb-case-study description: "Write TiDB customer case studies optimized for SEO, GEO (AI citations), and developer trust. Use this skill whenever the user wants to write, draft, create, or edit a case study, customer story, success story, or customer spotlight for TiDB or PingCAP. Also trigger when the user mentions 'case study', 'customer win', 'customer reference', 'proof point', 'social proof content', or asks to turn a customer conversation or deployment notes into a publishable story. This skill covers the full workflow from intake through final SEO-optimized output." --- # TiDB Case Study Writing Skill **Stage 4 — Content & Distribution** Write customer case studies for TiDB / PingCAP that rank in traditional search, get cited by AI answer engines, and genuinely help technical decision-makers evaluate TiDB. ## Why This Skill Exists Case studies are TiDB's highest-trust content asset. A developer evaluating distributed SQL databases will skim a landing page, but they'll *read* a case study from a company in their industry running a workload like theirs. These stories bridge PingCAP's engineering excellence and real-world customer problems — and they need to do three jobs simultaneously: 1. **Build trust with technical buyers** — CTOs, architects, and senior engineers who distrust marketing fluff 2. **Rank in search** — both traditional Google results and AI Overviews / Perplexity / ChatGPT citations 3. **Support the sales cycle** — give AEs a concrete story to share at the right moment The structure, tone, and optimization patterns below come from analyzing PingCAP's existing 20+ published case studies, competitor formats (Snowflake, CockroachDB, MongoDB, Databricks), current SEO/GEO research, and high-performing B2B infrastructure content in 2025-2026. --- ## Before using this skill You need: - [ ] `tidb-messaging-review` PASS — case studies are external proof points; claims must be pre-approved - [ ] Customer has approved being named — or anonymous pattern confirmed ("a fintech company in Southeast Asia") - [ ] At least 2 quantified outcome metrics (cost reduction %, latency delta, QPS achieved, downtime eliminated) - [ ] If benchmark or performance claims are included: metrics follow `@brain/playbooks/benchmark-standards.md` standards - [ ] Author's raw material: customer call notes, deployment summary, or customer-provided metrics If any of the above is missing, ask before drafting. --- ## Intake: What You Need Before Writing Before drafting, gather these inputs from the user. If information is missing, ask — don't guess on metrics or technical details. ### Required Inputs - **Customer name** and whether they've approved being named (if anonymous, use "[Industry] Company" pattern) - **Industry vertical** — e.g., fintech, e-commerce, gaming, SaaS/AI, automotive, logistics, media - **Region** — important for localization cues (APAC nuances differ from NA/EU) - **The problem** — what broke, what couldn't scale, what was costing too much. Get specific: table sizes, QPS numbers, latency targets, team size, prior database stack - **The solution** — what TiDB product (TiDB Cloud, TiDB Self-Managed, TiDB Cloud Starter), deployment topology, migration path, any companion tools (TiKV, TiFlash, TiCDC) - **The results** — hard metrics wherever possible (cost reduction %, latency improvement, QPS achieved, downtime eliminated, team hours saved). Aim for 3-5 quantified outcomes - **A quote** — even a rough one from the customer's engineer or technical leader. If unavailable, write a placeholder with guidance on what to capture ### Nice-to-Have Inputs - Architecture diagrams (before/after) - Migration timeline - Evaluation criteria (why TiDB won over alternatives) - Team context (how many engineers manage the database layer) --- ## Case Study Structure Use this structure as the backbone. Adapt section lengths based on story complexity — a simple migration story might be 800 words; a multi-phase HTAP transformation could be 1,500+. ### 1. Title (The Hook) The title is the single most important SEO and click-through element. It should pass the "would an engineer click this in search results?" test. **Formula:** `[Customer Name] + [Specific Quantified Result] + with TiDB` **Examples from PingCAP's published case studies:** - "How CardX Scales 3.4M Credit Accounts Without Downtime" - "BookMyShow.com: More Uptime, 30% Less Operational Cost with TiDB" - "Revving Up Efficiency: Transforming NIO's Data Strategy with TiDB" - "Dify.AI Consolidates Massive Database Containers into One TiDB" **What makes these work:** They lead with the customer and the outcome, not with TiDB. The reader sees themselves in the result before they see the product. **Avoid:** Generic titles like "How [Company] Uses TiDB" or "TiDB Case Study: [Company]". These fail the click test and rank poorly because they lack specificity signals that both search engines and AI models reward. Provide 2-3 title options for the user to choose from. ### 2. Snapshot Sidebar (The Scannable Summary) Place this at the top or as a right-rail sidebar. Engineers scan before they read. This box tells them in 5 seconds whether the story is relevant to them. ``` Company: [Name] Industry: [Vertical] Region: [Geography] Company Size: [Employees or scale indicator] Database Before: [MySQL / PostgreSQL / Aurora / MongoDB / sharded setup] TiDB Product: [TiDB Cloud / Self-Managed / Starter] Key Results: • [Metric 1 — e.g., "99.999% uptime achieved"] • [Metric 2 — e.g., "30% reduction in operational costs"] • [Metric 3 — e.g., "Query latency from 30s → 6s"] ``` This sidebar also feeds structured data for SEO (see the SEO & GEO section below). ### 3. Opening Paragraph (Definition-First for GEO) Start with a crisp, definitional sentence about the customer and their challenge. Research on AI citation behavior shows that pages whose opening sentence contains a clear definitional structure earn significantly higher citation rates in LLM-based search. **Pattern:** "[Customer] is a [what they do] serving [scale indicator]. When [specific technical challenge], they turned to TiDB to [outcome summary]." **Example:** "BookMyShow is India's largest online entertainment ticketing platform, processing millions of transactions during peak events. When their existing database infrastructure couldn't handle traffic spikes without manual intervention and rising operational costs, they migrated to TiDB — reducing operational costs by 30% while eliminating downtime during high-demand periods." This opening should be self-contained enough that an AI engine could cite it as a complete answer. ### 4. Challenge Section This is where technical credibility is built or lost. Be specific and honest about the pain. **Structure the challenge around:** - **Scale numbers** — table sizes, row counts, QPS, concurrent users, data growth rate - **Technical debt** — sharding complexity, manual operations, single points of failure - **Business impact** — what the technical problem cost in business terms (engineer hours, customer complaints, revenue risk, delayed features) - **Prior stack** — what database(s) they were using and why those hit limits **Tone:** Empathetic to the engineering team's situation, not dismissive of previous technology choices. A reader using MySQL right now should feel understood, not judged. **GEO optimization:** Include 2-3 specific data points in this section. AI engines heavily favor passages with verifiable, quantified claims over vague assertions. "Tables exceeding 2 billion records caused query timeouts during peak hours" is citable; "they had scaling issues" is not. ### 5. Why TiDB (Evaluation Context) This section is optional but high-value for SEO — it captures comparison-intent searches like "TiDB vs Aurora" or "distributed SQL for [use case]." Cover: - What alternatives were evaluated and why TiDB won - Specific TiDB capabilities that mattered (MySQL compatibility, HTAP, horizontal scaling, TiDB Cloud managed experience) - Migration effort — how hard was it to move? This is the #1 concern for technical evaluators Keep this factual and understated. The reader should draw their own conclusion. Avoid superlatives. ### 6. Solution Section Describe the implementation with enough technical detail that a peer architect could picture the deployment. **Include:** - TiDB product and deployment model (cloud provider, region, cluster topology) - Migration approach (big-bang vs. phased, use of TiCDC for live replication, dual-write period) - Architecture decisions (how TiFlash was used for analytics, TiKV configuration, any custom tuning) - Integration points (how TiDB fits with their broader stack — Kafka, Spark, Hive, application frameworks) - Timeline — how long from evaluation to production **Show, don't sell.** The implementation section should read like a technical blog post, not a brochure. Use specific version numbers, configuration choices, and trade-offs the team navigated. ### 7. Results Section The most important section for both conversion and AI citation. Structure results in three tiers: **Tier 1: Headline metrics** (the 2-3 numbers that go in the title and snapshot) - Always quantified: percentages, absolute numbers, or time comparisons - Before/after format when possible: "Query latency decreased from 30-40 seconds to 6-7 seconds" **Tier 2: Operational improvements** (what changed for the engineering team) - Reduced operational burden: "No engineer needs to be fully dedicated to database operations anymore" - Simplified architecture: "Consolidated from 500,000 database containers to a single TiDB cluster" - Developer velocity: faster feature development, less time on database firefighting **Tier 3: Business outcomes** (the "so what" for executives) - Revenue impact, customer experience improvement, ability to enter new markets - Cost savings with context (not just "saved money" but "reallocated 3 FTEs from DB ops to product features") **Formatting:** Use a mix of inline metrics and a callout box for the headline numbers. Repeat key metrics — readers scan, and the same number in the snapshot, results section, and conclusion reinforces the story. ### 8. Customer Quote A direct quote from a named engineer, architect, or technical leader adds authenticity that no amount of good writing can replicate. **If a quote is provided:** Place it after the results section, formatted as a blockquote with the speaker's name and title. **If no quote is available:** Write a placeholder with guidance: ``` > [Placeholder: Capture a quote from the customer's technical lead about > the most impactful change — ideally something specific like "We went > from 3 engineers managing shards to zero database firefighting" rather > than generic praise.] > > — [Name], [Title], [Company] ``` ### 9. Call to Action End with a single, clear next step. Match the CTA to the reader's likely intent: - **Technical reader:** "Explore TiDB's architecture →" or "Try TiDB Cloud Starter free →" - **Business reader:** "Talk to our team about your use case →" - **Related content:** Link to 1-2 related case studies in the same industry or use case --- ## Tone and Voice TiDB's case studies speak to engineers who are allergic to marketing speak. The tone should be: - **Technical but accessible** — assume the reader understands databases but don't assume they know TiDB's internals. Explain TiDB-specific concepts (HTAP, TiFlash, TiKV) briefly on first mention - **Honest and specific** — if the migration had rough patches, acknowledge them. Authenticity builds more trust than perfection - **Customer-centric** — the hero of the story is the customer's engineering team, not TiDB. They made the decision, they did the migration, they delivered the results. TiDB was the tool that enabled it - **Open-source aware** — many TiDB users came through the open-source community. Respect that path and the developer trust it represents. Avoid hard-sell language - **Regionally sensitive** — a case study about a Japanese gaming company reads differently than one about an Indian fintech. Adapt formality, context-setting, and business framing to the customer's market **Words to use:** scales, compatible, simplified, consolidated, eliminated, horizontal, real-time, zero-downtime, distributed **Words to avoid:** revolutionary, game-changing, best-in-class, seamless (unless quoting the customer), enterprise-grade (overused, says nothing) --- ## SEO & GEO Optimization Load `@brain/playbooks/seo-geo-standards.md` for universal principles (definition-first opening, stat density, entity clarity, headline formula, freshness rules). The following covers case-study-specific patterns on top of those foundations. ### Case Study Keyword Clusters Each case study should target: - `[industry] + distributed SQL / database scaling / MySQL alternative` - `TiDB + [use case]` (e.g., "TiDB for fintech", "TiDB real-time analytics") - `[competitor migration]` (e.g., "migrate from Aurora to TiDB", "MySQL sharding alternative") ### On-Page Essentials - URL slug: `/case-study/[customer]-[key-result]-with-tidb/` - Meta description (under 160 chars): lead with the result, include customer name and industry - Alt text on any architecture diagrams describing what the diagram shows - Internal links: TiDB product page for the product used + 1-2 related case studies in same industry ### Schema Markup (note to web team) ``` Recommend: Article schema with: - author (PingCAP or specific author with credentials) - datePublished / dateModified (freshness signal) - about: the customer company (as an Organization entity) - mentions: TiDB (as a SoftwareApplication entity) ``` ### FAQ Section for AI Overviews Consider ending with a 2-3 question FAQ that directly answers comparison queries like "Is TiDB good for [use case]?" This format is heavily cited in AI Overviews and Perplexity. --- ## Output Format Deliver the case study as a Markdown file with: 1. YAML frontmatter: title, customer, industry, region, products_used, publish_date, primary_keyword, meta_description 2. The full case study body following the structure above 3. A `## SEO Notes` section at the end (not for publication): target keywords, internal linking suggestions, schema markup recommendations, suggested social snippets Save the file with the naming convention: `case-study-[customer-slug].md` --- ## Pairs with - `tidb-messaging-review` — prerequisite gate; all claims must pass before this skill runs - `tidb-benchmark-narrative` — if performance metrics are central to the story - `tidb-tech-story` — for technical deep-dives that the case study links to - `tidb-channel-copy` — downstream; adapt the case study headline and key metrics for social - `tidb-content-review` — final gate before publishing - `tidb-brand-voice` — naming accuracy and voice standards - `@brain/knowledge/product.md` — product capability reference and approved terminology - `@brain/playbooks/messaging.md` — approved proof points and positioning - `@brain/playbooks/benchmark-standards.md` — if performance claims are included - `@brain/playbooks/seo-geo-standards.md` — universal SEO/GEO optimization principles