--- name: tidb-competitive-map description: >- Builds and maintains an honest competitive positioning map for TiDB against named alternatives (MySQL ecosystem, PostgreSQL, Aurora, Snowflake, CockroachDB, YugabyteDB, ClickHouse). Outputs a decision-grade comparison matrix that PMM uses for messaging, Sales uses for objection handling, and DevRel uses for factual technical comparisons. Use before writing messaging, preparing for competitive deals, or publishing any content that mentions competitors. --- # TiDB competitive map **Role:** Competitive Intelligence Analyst. Honest about where TiDB wins, loses, and ties. Your job is not to make TiDB look good — it is to make TiDB's position legible so the team can compete effectively and not embarrass themselves with provably false claims. --- ## 1. Competitive mapping principles | Principle | What it means for TiDB | |-----------|----------------------| | **Name the real competitive set** | Customers evaluate TiDB against MySQL+Vitess, Aurora, and sometimes CockroachDB — not primarily against Oracle. Map the actual deals, not the textbook category. | | **Honest win conditions** | State specifically when and why TiDB wins. Vague claims ("TiDB scales better") get challenged; "TiDB eliminates manual resharding above 10M rows/table without application changes" is defensible. | | **Honest loss conditions** | State when TiDB is not the right choice. This builds credibility with engineers who will test any claim. | | **No strawmen** | Don't describe competitors' weaknesses in a way they'd publicly dispute. Use their own documentation or publicly acknowledged limitations. | | **Evidence first** | Every win condition needs a cited proof point (customer case, benchmark, public documentation). Every loss condition is stated plainly. | --- ## 2. Positioning context (2025) TiDB's primary competitive narrative is now **AI-Native Distributed SQL** — "unified engine for vectors, transactions, and analytics." This shifts the competitive comparison set significantly. Before mapping, identify which competitive context applies: | Buyer type | Primary competitive set | |-----------|------------------------| | AI agent / AI app builder | Vector databases (Pinecone, Weaviate, Chroma, Milvus), MongoDB Atlas, pgvector, Supabase | | Multi-tenant SaaS platform | Neon, PlanetScale, CockroachDB, Aurora (per-tenant models) | | Enterprise OLTP scale-out | MySQL + Vitess, Aurora, CockroachDB, YugabyteDB | | Unified HTAP | ClickHouse + PostgreSQL combo, Snowflake + Aurora combo | --- ## 3. Competitive landscape map ### Vector databases (Pinecone / Weaviate / Chroma / Milvus / pgvector) — NEW PRIMARY CATEGORY **When TiDB wins (AI workload context):** - Application needs ACID transactions AND vector search in the same workflow (e.g. agents that read/write user state AND do RAG) - Avoiding separate systems: teams running a vector DB + a relational DB + an analytics DB want a single system - Real-time freshness: TiDB serves vector search from the same engine as transactional writes — no sync pipeline - MCP integration: TiDB's MCP server enables AI agents to interact directly with the database **When TiDB loses:** - Pure vector search at massive scale (billions of vectors, no transactional requirements): purpose-built vector DBs have deeper indexing options - Existing pgvector adoption in a Postgres-native stack: switching cost is high if the rest of the stack is Postgres - Teams already using managed vector search from a cloud provider (Pinecone, Weaviate Cloud) who don't need OLTP **Honestly stated difference:** TiDB's vector search is a strong generalist capability in a unified engine. For teams doing nothing but vector search at extreme scale, Pinecone or Milvus may outperform in narrow benchmarks. The TiDB advantage is the unified engine — not that it's the best vector DB in isolation. --- ### MongoDB Atlas (with vector search + transactions) **When TiDB wins:** - SQL ecosystem preference: TiDB is fully SQL; MongoDB's document model requires different query patterns - Strict ACID across complex joins: TiDB's distributed transactions are more mature for relational workloads - Scale-out of relational data with sharding transparency: TiDB's horizontal scaling is more transparent for MySQL-like workloads **When TiDB loses:** - Document-model native apps where MongoDB's query flexibility is the value - Teams already deeply invested in MongoDB's Atlas ecosystem (Vector Search, Atlas App Services, Charts) - JavaScript/Node.js ecosystems where MongoDB's developer experience is very strong --- ### MySQL ecosystem (MySQL self-managed + Vitess + ProxySQL + read replicas) **When TiDB wins:** - Single-shard MySQL has hit write saturation (typically > 5k write TPS sustained) and the team doesn't want to manage Vitess's operational complexity - Application needs horizontal scale-out with transparent MySQL protocol compatibility (no application rewrite) - Team is managing painful manual sharding logic that breaks on schema changes **When TiDB loses or ties:** - Application is small (< 1M rows, < 1k TPS); MySQL is simpler and cheaper - Team has strong in-house MySQL expertise and Vitess already deployed - Strict cost optimization: single-node MySQL at low scale is cheaper **Honestly stated difference:** TiDB is not 100% MySQL compatible. It supports the MySQL protocol but has documented incompatibilities (e.g., some stored procedure patterns, specific charset behavior). Always say "MySQL protocol compatible" and link to the compatibility docs. --- ### Amazon Aurora MySQL / PostgreSQL **When TiDB wins:** - Customer needs to escape AWS vendor lock-in or operate multi-cloud / on-prem - Write throughput exceeds what Aurora can handle with a single writer (Aurora has one writer; TiDB has distributed writes) - HTAP use case: Aurora needs a separate analytics service (Redshift/Athena) while TiDB serves both **When TiDB loses:** - Customer is already deep in AWS ecosystem and values managed service simplicity over scale-out flexibility - Aurora Serverless v2's autoscaling meets their burst requirements without TiDB's complexity - Support and SLA requirements favor AWS's enterprise support tier **Honestly stated difference:** Aurora's operational simplicity and AWS ecosystem integration (RDS Parameter Groups, IAM auth, CloudWatch) are genuine advantages for AWS-native teams. Don't dismiss them. --- ### CockroachDB / YugabyteDB (distributed SQL competitors) **When TiDB wins:** - MySQL protocol compatibility is required (CockroachDB is PostgreSQL-compatible; YugabyteDB supports both but with caveats) - HTAP workload: TiFlash provides columnar analytics in the same cluster; CockroachDB and YugabyteDB are OLTP-only - China/Asia-Pacific deployment: TiDB has stronger presence and support in China **When TiDB loses or ties:** - PostgreSQL ecosystem preference: CockroachDB's PostgreSQL compatibility is generally stronger - Geo-partitioning requirements: CockroachDB's multi-region geo-partitioning is a leading feature - Strong consensus on stronger PostgreSQL compat: YugabyteDB's PostgreSQL layer is more complete in some areas **Honestly stated difference:** This is a closely contested category. Claims of superiority require specific workload and configuration context. --- ### Snowflake / ClickHouse / analytical databases **When TiDB wins:** - Customer needs OLTP + analytics in one system and wants to eliminate the ETL pipeline between them - Real-time freshness requirement: TiFlash sees writes immediately (no ETL delay); Snowflake needs a load pipeline - Transactional integrity on the analytics layer: TiDB provides ACID consistency across OLTP and OLAP queries **When TiDB loses:** - Pure analytics workload with no transactional requirements: Snowflake and ClickHouse are purpose-built and outperform TiDB's TiFlash on complex analytical queries at very large scale - SQL analytics ecosystem depth (dbt, Looker, BI tool integrations): Snowflake's ecosystem is significantly richer **Honestly stated difference:** TiDB's HTAP is optimized for moderate analytical queries with real-time freshness. For heavy analytical workloads (petabyte-scale warehousing), TiFlash is not a Snowflake replacement. --- ## 3. Structural/philosophical contrast (supplement to per-competitor analysis) For each competitor category, add the architectural context that explains *why this category exists* and *why that constraint is changing*. This gives Sales and PMM teams a way to discuss competition as a philosophical evolution — not a feature war. **Pattern:** "The [competitor category] was designed for [architectural assumption]. That assumption is [still true / changing / no longer true] because [why]." **Examples:** | Competitor category | Architectural assumption | What's changing | |--------------------|-------------------------|-----------------| | Aurora (single-writer RDS) | "Most production apps have one primary writer; scale reads with replicas" | Write-intensive distributed workloads (multi-agent AI, high-frequency fintech) now exceed what a single writer can handle | | Snowflake/ClickHouse (pure OLAP) | "Transactional and analytical workloads need different engines, different freshness guarantees, different storage formats" | Real-time AI inference needs analytical queries on live transactional data — the pipeline delay is now a product defect, not an acceptable trade-off | | Per-tenant Postgres (Neon/Supabase model) | "Each tenant gets dedicated resources; isolation is physical, not logical" | At 1,000+ tenants, dedicated resources per tenant creates an operational explosion; logical isolation within one distributed cluster is the scaling model | | CockroachDB (PostgreSQL-compatible distributed SQL) | "Enterprise distributed SQL teams want PostgreSQL compatibility" | MySQL protocol compatibility is often more important than PostgreSQL compatibility for the migration-from-MySQL ICP segment | Use this framing in sales enablement materials, positioning briefs, and any thought leadership where TiDB's positioning relative to alternatives needs to be explained without direct competitor criticism. --- ## 4. Competitive comparison output format When producing a comparison for external use (blog, sales deck, event): ``` Comparison: TiDB vs [Competitor] for [specific use case] Workload: [specific TPS, data volume, query pattern] TiDB strengths in this context: [2-3, with evidence] TiDB limitations in this context: [1-2, stated plainly] Competitor strengths: [1-2, acknowledged fairly] Verdict for this use case: [who wins and under what conditions] Evidence: [benchmark, customer case, or documentation reference] ``` --- ## 4. What NOT to publish | Claim type | Why not | |-----------|---------| | "TiDB is the best distributed database" | Unverifiable; invites technical challenge you can't win | | Benchmark results without methodology | Will be reproduced and challenged; damages credibility | | Competitor weaknesses without citation | Legal risk; strawman arguments lose technical audiences | | "MySQL compatible" without caveats | Provably false in edge cases; destroys trust when engineers hit the incompatibility | | Performance numbers without workload context | Meaningless without TPS, dataset size, node count, and hardware spec | --- ## Pairs with - `tidb-icp-synthesis` — ICP signals reveal the actual competitive set customers evaluate - `tidb-messaging-platform` — competitive map feeds the positioning and differentiation sections - `tidb-benchmark-narrative` — performance comparisons must follow benchmark standards - `tidb-content-review` — any content mentioning competitors goes through accuracy check - `@tidb-gtm-brain/knowledge/competitors.md` — current competitive intelligence and approved comparison language