---
name: tidb-messaging-platform
description: >-
  Builds TiDB's complete messaging platform: one-sentence positioning, value
  proposition matrix by ICP segment, tagline options, tier-specific messaging
  (Starter/Essential/Dedicated/Self-Managed), core proof points, and banned
  phrases. This is PMM's core output — the document that all external content
  must be consistent with. Use when launching a new product, entering a new
  segment, or when messaging has drifted. Requires ICP Card, competitive map,
  and PM product narrative brief as inputs.
---

# TiDB messaging platform

**Role:** PMM Architect. You translate technical facts (from PM) and customer intelligence (from ICP research) into market language that drives conviction in buyers and credibility with engineers. The messaging platform is not a tagline collection — it is a decision system that every content creator, sales rep, and executive uses to stay consistent.

---

## Required inputs

Before writing. Missing inputs produce fragile messaging that will be challenged.

- [ ] ICP Card (from `tidb-icp-synthesis`) — at minimum: Core ICP segment, deciding language, alternatives
- [ ] Competitive map (from `tidb-competitive-map`) — primary competitive displacement known
- [ ] PM product narrative brief (from `tidb-product-narrative`) — capabilities, proof points, "what this is NOT"
- [ ] GTM Brief (from `tidb-gtm-brief`) — motion selection, segment priority, launch scope

---

## 1. Positioning statement

The single sentence that answers: "What is TiDB, for whom, and why does it win?"

**Format:** [Product] is the [category] that [primary differentiation] for [primary ICP], enabling them to [primary outcome].

**Current positioning (AI-Native era):**
> TiDB is the AI-native distributed SQL database that unifies vectors, transactions, and analytics in one engine, enabling AI application builders to scale agent workloads without managing separate data systems.

**Rules for the positioning statement:**
- One sentence. If it needs two sentences, it's not positioned yet.
- "AI-native" before "distributed SQL" — category frame must reflect the lead narrative
- Test it: can a Sales rep say this cold? Can a customer repeat it to their CTO? If not, revise.

---

## 2. Value proposition matrix by ICP segment

Each segment needs its own version of "why TiDB." Don't use the same copy for AI builders and DBA-led enterprise migrations.

| ICP Segment | Primary pain | TiDB value prop | Proof point |
|-------------|-------------|----------------|-------------|
| **AI agent builders** | Separate vector DB + OLTP DB → inconsistent state, sync lag, two systems to operate | "Unified vectors, transactions, and analytics in one SQL call — ACID consistency across your agent's full context" | Manus: 1M+ DB tenants; Dify: consolidated 500K containers |
| **AI SaaS / multi-tenant platforms** | Per-tenant DB clusters exploding in count; operational overhead grows with customers | "One TiDB cluster, thousands of isolated tenants — scale customers without scaling ops" | Atlassian: 750+ Postgres clusters → 16 TiDB clusters |
| **Scale-out MySQL** | Manual sharding breaks on schema changes; Vitess is complex to operate | "MySQL protocol compatible, horizontally scales transparently — no application rewrites, no Vitess ops burden" | Plaid: 96 Aurora services migrated |
| **Unified HTAP (ETL elimination)** | ETL pipeline between OLTP and analytics creates data staleness and engineering overhead | "Fresh analytical queries on live transactional data — eliminate the ETL layer entirely" | [Internal case or customer reference needed] |
| **Fintech / high-stakes OLTP** | Needs strict ACID at high TPS with disaster recovery; Aurora has single-writer limits | "Distributed ACID transactions, 99.999% availability, multi-region DR — built for production-critical financial workloads" | Plaid, Square, Bolt |

---

## 3. Tagline options (select per campaign context)

**Lead tagline (AI-Native era):**
> Scale Your AI Agents Without Compromise

**Supporting taglines by use case:**
- AI workload: "One database. Vectors, transactions, analytics."
- Scale-out: "MySQL protocol compatible. Horizontally scalable." ⚠ Do not use "infinitely" — use "horizontally scalable" per banned phrases list
- HTAP: "Transact and analyze. Same data. No ETL."
- Developer: "SQL you know. Scale you need."
- Enterprise: "Mission-critical SQL at any scale."

**Selection rules:**
- Use the lead tagline for brand-level communications (homepage, ads, conference)
- Use use-case taglines for ICP-specific landing pages, targeted content, and segment campaigns
- Never mix taglines within one piece of content

---

## 4. Tier-specific messaging

Each TiDB tier has a distinct value proposition and target user. Mismatching tier and audience is a common messaging failure.

| Tier | Target user | Primary value prop | Entry point |
|------|------------|-------------------|-------------|
| **TiDB Cloud Starter** | AI developers, startups, teams prototyping | "Start free. Scale automatically. No cluster management. Vector search included." | Free tier (25 GiB, scales to zero); PLG motion |
| **TiDB Cloud Essential** | Growing teams moving to production; autoscaling workloads | "Production-grade elastic scale — pay for what you use" | Preview; PLG → SLG |
| **TiDB Cloud Dedicated** | Enterprise teams needing dedicated resources, SLA guarantees | "Guaranteed performance, SLA-backed availability, enterprise security" | SLG evaluation |
| **TiDB Self-Managed** | Enterprises with on-prem / private cloud requirements; OSS contributors | "Full control, open-source foundation, PingCAP support available" | OSS download; SLG for support |

**Note on TiDB X:** TiDB X is the underlying elastic engine powering Starter and Essential — it is NOT a separately purchasable tier. Reference it as "powered by TiDB X" for engineering audiences; do not market it as a product SKU.

---

## 5. Core proof points (approved for external use)

| Claim | Evidence | Usage permission | Limitation to disclose |
|-------|---------|-----------------|----------------------|
| "1M+ DB tenants in 2-week migration" | Manus case study | Yes — public | Manus-specific migration context |
| "750+ Postgres clusters → 16 TiDB clusters" | Atlassian case study | Yes — public | Enterprise consolidation use case |
| "96 Aurora services migrated" | Plaid case study | Yes — public | Plaid's fintech scale context |
| "10x P99 latency improvement" | Pinterest | Yes — public | Specific graph service workload |
| HTAP real-time freshness claims | TiFlash architecture | Yes — with methodology | Workload-dependent; cite test setup |

**Rule:** Every proof point in external content must trace to an entry in this table or go through `tidb-content-review` before use.

---

## 6. Banned phrases

These phrases trigger immediate revision in any TiDB external content. Maintain and update this list.

**AI-specific hype (2025 additions):**
- "AI-ready" (meaningless — everything claims this)
- "the leading AI database"
- "purpose-built for AI" without specifying which AI workload
- "seamless AI integration"
- "next-generation AI infrastructure"

**General TiDB overclaims:**
- "fully MySQL compatible" (say "MySQL protocol compatible" with link to compatibility docs)
- "zero downtime" (say "rolling upgrade with minimal disruption per node")
- "HTAP" without explanation for non-technical audiences
- "scales infinitely" (scales horizontally to [N] nodes — cite the actual tested scale)
- "real-time" without latency specification
- Any benchmark claim without full methodology disclosure

**Filler language (signals weak messaging):**
- game-changing, revolutionary, groundbreaking
- seamless, frictionless, effortless  
- best-in-class, industry-leading
- powerful, robust (without specific proof)
- leverage (use "use")

---

## 7. Extended language bank

### Friction-elimination framing (pair with capability framing)

For each core capability, the messaging platform should carry both a *capability frame* (what it does) and a *friction-elimination frame* (what it lets the team stop doing). Use the friction frame in developer-facing content; use the capability frame in product documentation and enterprise sales materials.

| Capability | Capability frame | Friction-elimination frame |
|-----------|-----------------|--------------------------|
| Horizontal scale-out | "Distributed writes across N nodes without application SQL changes" | "Eliminates the MySQL sharding project when you hit the write ceiling" |
| HTAP (TiFlash) | "Analytical queries on live transactional data in the same engine" | "Eliminates the ETL pipeline and the data staleness it creates" |
| Multi-tenant isolation | "Workload isolation per tenant within one distributed cluster" | "Eliminates the operational explosion of managing one cluster per enterprise customer" |
| Database branching | "Instant copy-on-write database branch in milliseconds" | "Eliminates the staging drift problem — every environment stays in sync" |
| Auto-scaling | "Compute scales to zero during idle; scales up under load automatically" | "Eliminates the idle compute cost and the capacity planning ritual" |

### Developer emotional outcomes

Beyond rational job-to-be-done, developers have emotional outcomes they are trying to reach. These phrases belong in developer-facing content (tech stories, developer blog, HN, DevTo) and ICP-specific messaging.

**Approved emotional outcome language:**
- "ship faster without worrying about breaking things" (velocity + safety combined)
- "experiment without fear" (psychological safety for development)
- "no operational overhead" (freedom from infrastructure babysitting)
- "production-grade in minutes" (legitimacy + speed)
- "no rewrites required" (MySQL migration ICP — relief from sunk-cost fears)

These are not hype phrases — they describe real emotional states engineers want to reach. Use them in content where the engineering audience is the primary reader. Do not use in executive-facing or analyst-facing content (stick to rational value props there).

### Forward-looking category language (owned terms)

These are the category terms TiDB is investing in — use them consistently enough across content that they become associated with TiDB in the reader's mind.

| Term | Context | Definition to use in content |
|------|---------|------------------------------|
| "AI-native distributed SQL" | All positioning, brand-level | "A database built for the workload patterns of AI agents: unified vectors, transactions, and analytics in one engine" |
| "Unified transactional and analytical" | HTAP positioning | "Running OLAP queries on live OLTP data in the same engine — no separate pipeline" |
| "Multi-tenant data isolation" | AI SaaS segment | "One cluster, thousands of tenants, each with isolated workload and data boundaries" |
| "Horizontal scale as a deployment option" | Scale-out MySQL | "Adding nodes is a config change, not an engineering project" |
| "Agent-native data layer" | AI agent builders | "The data primitive built for workloads that require ACID writes, vector reads, and analytical aggregation in the same transaction" |

### Enabler framing (for co-marketing and partner contexts)

When TiDB appears in partner content, co-marketing materials, or integration announcements, position as the data layer enabling the partner's success — not as the product vendor pitching features.

**Enabler framing patterns:**
- "[Partner] built [capability] on TiDB because [specific capability match]"
- "TiDB serves as the data layer for [Partner]'s [specific workflow]"
- "[Partner]'s [scale metric] runs on TiDB"

**Avoid in partner contexts:**
- "TiDB provides [Partner] with enterprise-grade database capabilities"
- "Powered by TiDB's industry-leading distributed SQL"

The enabler framing earns more credibility with engineers reading partner content because it positions TiDB as infrastructure, not vendor.

---

## 8. Messaging consistency checks

Run before finalizing:

- [ ] Positioning statement is in the document (or clearly referenced)
- [ ] ICP segment is matched to the correct value prop (not the generic statement)
- [ ] Tier is specified (Starter / Essential / Dedicated / Self-Managed)
- [ ] All capability claims trace to the proof point table
- [ ] "What this is NOT" limitations from PM brief are reflected or explicitly excluded with reason
- [ ] Banned phrases list has been applied
- [ ] Chinese market content follows localization principles (see `tidb-brand-voice`)

---

## Pairs with

- `tidb-icp-synthesis` — deciding language from ICP card populates this document
- `tidb-product-narrative` — PM proof points and capability framing are the factual foundation
- `tidb-competitive-map` — differentiation statements require competitive accuracy
- `tidb-messaging-review` — this document goes through review before it drives external content
- `tidb-brand-voice` — voice standards apply on top of all messaging
- `@tidb-gtm-brain/playbooks/messaging.md` — approved messaging snapshots for quick reference