# TiDB ICP Reference

> Validated ICP segments for TiDB GTM. Skills load this file to align targeting, messaging, and channel decisions.  
> Update after every 10+ new customer interviews or when ICP shift is observed in pipeline data.

Last updated: 2026-07-24  
Evidence base: Public customer cases from official pingcap.com solutions and AI pages (fetched 2026-07-24); deciding language is inferred from public materials — validate with real sales/CS interview data before citing as "customer language"

---

## Segment 1: AI Agent Builders (Primary — AI-Native positioning)

**Segment name:** AI Agent Builders  
**Company type:** AI startups, AI platform companies, developer tools companies building agentic AI products  
**Role:** Backend engineers, AI engineers, founding engineers  
**Company stage:** Seed to Series B typically; may be larger AI teams at enterprises  

**Trigger:**
The team is running a separate vector database (Pinecone, Chroma, Weaviate) alongside a relational database (PostgreSQL, MySQL) for their AI application. They're hitting: inconsistent state between the two systems, sync pipeline maintenance overhead, latency from the pipeline, or the architectural complexity of coordinating writes across two systems. They need ACID consistency across agent state reads and writes.

**Job-to-be-done:**
"When our AI agent needs to retrieve similar past interactions AND update the agent's state in the same workflow, I want a database that handles both operations in one ACID transaction, so I don't have to build and maintain a sync pipeline between two separate systems."

**Alternatives they evaluated:**
- pgvector (PostgreSQL extension) — lacks TiDB's horizontal scale-out for tenant growth
- MongoDB Atlas with vector search — document model; less natural for relational workloads
- Keep separate vector DB + relational DB — the problem they're solving for

**Deciding language (exact phrases from customers/community):**
- "one database for vectors and transactions"
- "ACID consistency for agent state"
- "eliminate the sync pipeline"
- "unified vector and SQL"
- "scale to many tenants without ops explosion"

**Validated customer examples (public):**
- **Manus** (AI agent platform): "1M+ database tenants"; two-week migration to TiDB Cloud; powers context persistence behind agent swarms and full-stack app generation — pingcap.com/case-study/manus-agentic-ai-database-tidb/
- **Kimi** (K2.6 agent hosting platform): "millions of agent-created databases, provisioned in under a second"; 10M+ tenants; zero per-site compute cost at idle — pingcap.com/case-study/kimi-2-6-agent-hosting-platform-tidb-cloud/
- **Plaud** (AI hardware / smart recording device): migrated from MySQL + S3 to TiDB Cloud; eliminated S3 retrieval latency; 10x QPS improvement; 2M+ users across 170 countries — pingcap.com/case-study/how-plaud-eliminated-s3-latency-limitless-scale/
- **Dify** (AI workflow platform): consolidated backend infrastructure; unified vectors, documents, and relational data — pingcap.com/ai/agentic-ai
- **Rengage** (marketing automation): real-time user context for agent decisions — same source
- **Toprism** (business intelligence): hybrid semantic + SQL queries — same source

**Motion fit:** PLG (TiDB Cloud Starter free tier as entry) → SLG upgrade at scale  
**Channels:** LangChain Discord, AI Engineer Summit, Hugging Face community, GitHub, pytidb/MCP ecosystem, AI newsletters (TLDR AI, The Batch)

**Red flags (not this segment):**
- Pure analytics workload with no transactional requirements
- Already using a cloud-native vector DB with no plans to add OLTP

---

## Segment 2: AI SaaS / Multi-Tenant Platform Builders

**Segment name:** AI SaaS Multi-Tenant  
**Company type:** B2B SaaS companies with AI features; AI platforms serving many customers  
**Role:** Platform engineers, SREs, CTOs/VPs of Engineering  
**Company stage:** Series A to Series C; growing customer base  

**Trigger:**
The company is running one-database-per-tenant (often PostgreSQL or MySQL) and hitting the operational ceiling. At 100+ tenants, cluster management is becoming a full-time job. At 1,000+ tenants, it's untenable. They need tenant isolation without per-tenant infrastructure.

**Job-to-be-done:**
"When we add a new enterprise customer, I want to provision an isolated database environment for them without spawning a new cluster, so that our operational overhead doesn't grow linearly with customer count."

**Alternatives they evaluated:**
- Neon / PlanetScale — newer managed services; may lack enterprise features or global scale
- CockroachDB — distributed SQL alternative; lacks HTAP
- RDS / Aurora — per-tenant model is what they're running; hitting the operational limit

**Deciding language:**
- "database per tenant doesn't scale operationally"
- "tenant isolation at scale"
- "1000 tenants, not 1000 clusters"
- "consolidate without compromising isolation"

**Validated customer examples (public):**
- **Atlassian**: consolidated 750+ Postgres clusters → 16 TiDB clusters — pingcap.com homepage
- **Pinterest**: 10x P99 latency improvement on graph service — pingcap.com homepage
- **Conga** (SaaS): "transactional and analytical workloads with exceptional performance" — pingcap.com/solutions/saas

**Motion fit:** SLG (architecture consultation required); PLG evaluation often precedes sales conversation  
**Channels:** Enterprise SaaS engineering blogs, infrastructure podcasts, technical case studies (Atlassian), SRE community  

**Red flags (not this segment):**
- Single-tenant product with no multi-tenancy requirement
- Very early stage (< 10 customers) where operational complexity hasn't yet materialized

---

## Segment 3: Scale-Out MySQL (Core historical segment)

**Segment name:** Scale-Out MySQL  
**Company type:** E-commerce, fintech, gaming, social platform — any high-write-volume OLTP workload  
**Role:** DBAs, backend engineers, infrastructure leads  
**Company stage:** Growth to enterprise; usually > 3 years old, > $10M ARR  

**Trigger:**
MySQL write throughput is saturating (typically > 5k–10k write TPS sustained). Manual sharding is in place and causing operational pain: cross-shard transactions are failing, schema changes are paralyzed, new features require sharding logic changes. Or: Vitess was considered or deployed, and the operational complexity is a problem.

**Job-to-be-done:**
"When our MySQL cluster hits the write wall and manual sharding is breaking our schema evolution velocity, I want a database that handles horizontal scale-out transparently with MySQL protocol compatibility, so I can keep moving fast without a full application rewrite."

**Alternatives they evaluated:**
- Vitess — horizontal MySQL sharding; complex to operate; requires sharding key discipline
- Aurora — still single-writer; doesn't solve write scale-out
- PostgreSQL + Citus — different protocol; requires application changes

**Deciding language:**
- "MySQL compatible so we don't have to rewrite"
- "transparent horizontal scaling"
- "no manual sharding"
- "didn't want to run Vitess"
- "Black Friday / 11.11 write saturation"

**Validated customer examples (public):**
- **LINE, Shopee, Bolt, Streak**: MySQL modernization — pingcap.com/solutions/modernize-mysql-workloads
- **Rakuten, Flipkart, Zhihu, Ninjavan, ZTO Express**: e-commerce scale — pingcap.com/solutions/e-commerce
- **ZTO Express**: 25% reduction in per-order costs — pingcap.com/solutions/enable-operational-intelligence
- **Cost signal**: 52–67% infrastructure cost savings vs RDS MySQL at 8,000 QPS / 500GB / aws-us-east-1 — pingcap.com/solutions/lower-infrastructure-costs

**Motion fit:** SLG primary; migration complexity requires sales + technical support  
**Channels:** DBA communities, MySQL engineering blogs, high-scale engineering conference talks, database-specific newsletters  

**Red flags:**
- Small scale (< 1M rows, < 1k write TPS) — MySQL self-managed is simpler and cheaper
- Strong Vitess expertise in-house and no desire to change

---

## Segment 4: HTAP / ETL Elimination

**Segment name:** HTAP / Eliminate the ETL Pipeline  
**Company type:** Data-intensive businesses where OLTP data needs real-time analytics  
**Role:** Data engineers, platform engineers, CDOs, analytics leads  

**Trigger:**
Running separate OLTP (MySQL/PostgreSQL) and analytics (ClickHouse, Snowflake) stacks. The ETL pipeline between them is causing: data freshness lag (minutes to hours), engineering overhead, consistency issues where OLAP queries return stale data during high-write periods, and cost of maintaining two database systems.

**Job-to-be-done:**
"When my analytics team needs fresh data to make real-time business decisions but our ETL pipeline introduces 30-minute lag, I want analytics that run on live transactional data, so I can eliminate the pipeline and the staleness problem simultaneously."

**Deciding language:**
- "real-time analytics on live data"
- "eliminate the ETL"
- "HTAP in one system"
- "TiFlash for analytics without a separate pipeline"
- "no data warehouse just for this"

**Validated customer examples (public):**
- **Catalyst**: "60x faster performance" vs prior analytical stack — pingcap.com/solutions/enable-operational-intelligence
- **Conga**: handles both transactional and analytical workloads — pingcap.com/solutions/saas

**Motion fit:** SLG (enterprise evaluation; affects data architecture significantly)  
**Channels:** Data engineering conferences, ClickHouse community, data stack newsletters  

---

## Segment 5: Fintech / High-Stakes OLTP

**Segment name:** Fintech / High-Stakes OLTP  
**Company type:** Payments, banking, lending, insurance, trading platforms  
**Role:** Engineering leads, platform engineers, CTOs  

**Trigger:**
Aurora or MySQL hitting write limits; disaster recovery requirements exceeding what a single-writer system can provide; compliance requirements for multi-region or data residency; or cost at scale making Aurora too expensive.

**Deciding language:**
- "financial-grade ACID"
- "multi-region active-active"
- "99.999% availability"
- "Aurora replacement for our scale"

**Validated customer examples (public):**
- **Plaid**: "99.99% uptime with increased developer velocity"; zero-downtime upgrades; migrated 96 Aurora services — pingcap.com/solutions/fintech
- **Chainbase** (Web3 infrastructure): "reduced infrastructure costs by 50%" — same source
- **SB Payment Service**: zero-downtime scaling for growing payment systems — same source

**Motion fit:** SLG (enterprise; long evaluation; compliance requirements)  
**Channels:** Fintech infrastructure conferences, Plaid/Square/Bolt case study amplification  

---

## ICP quick-reference: motion and channel map

| Segment | Primary motion | CTA type | Key channels |
|---------|---------------|---------|-------------|
| AI Agent Builders | PLG → SLG | TiDB Cloud Starter signup / MCP demo | LangChain Discord, GitHub, AI newsletters |
| AI SaaS Multi-Tenant | SLG | Architecture workshop | LinkedIn engineering, case studies |
| Scale-Out MySQL | SLG | Technical deep-dive / migration assessment | HN, DBA communities, MySQL engineering |
| HTAP / ETL Elimination | SLG | Demo / POC | Data engineering conferences, ClickHouse community |
| Fintech OLTP | SLG | Case study + SE consultation | Fintech infrastructure events |