# TiDB Competitive Intelligence Reference

> Approved competitive positioning and comparison language. Load before writing any content that mentions competitors.  
> **Never cite competitor weaknesses without a public source. Legal reviews competitive claims.**

Last updated: 2026-07-24  
Sources: pingcap.com official compare pages (fetched 2026-07-24)

---

## Competitive context by buyer type

| Buyer | Primary competitive set | TiDB's position |
|-------|------------------------|----------------|
| AI agent builder | Pinecone, Weaviate, Milvus, pgvector, MongoDB Atlas, Redis, Qdrant | Unified engine (TiDB) vs specialized vector store + separate OLTP; 90% of new daily TiDB Cloud clusters created by AI agents |
| Multi-tenant SaaS | Neon, PlanetScale, CockroachDB, Aurora | Only system combining distributed SQL + MySQL compat + native HTAP + Kubernetes in one; workload isolation without per-tenant clusters |
| Scale-out MySQL | Vitess, Aurora, RDS MySQL | Distributed write scale-out vs Aurora's single-writer; simpler ops vs Vitess (no proxy layer); 52–67% cost savings vs RDS MySQL at 8,000 QPS / 500GB |
| HTAP / ETL elimination | ClickHouse+PostgreSQL, Snowflake+Aurora (separate stacks) | Unified system + no ETL + real-time OLAP on same data as OLTP |
| Fintech OLTP | Aurora, CockroachDB, Oracle (legacy) | Multi-region active-active + distributed ACID + 99.999% availability |
| Best distributed SQL | CockroachDB, YugabyteDB, Spanner | MySQL compat + HTAP + first-class Kubernetes; HTAP is unique differentiator |

Sources: pingcap.com/compare/best-database-for-ai-agents, /best-distributed-sql, /best-databases-for-saas, /mysql-vs-tidb

---

## Vector databases (Pinecone / Weaviate / Milvus / Chroma)

**TiDB's angle:** Unified engine — AI applications that need vector similarity AND OLTP transactions AND real-time analytics in one system. TiDB is not a replacement for a purpose-built vector DB; it is the choice when ACID + vectors + SQL matter together.

**Validated differentiation:**
- TiDB uses HNSW-based vector indexing with SQL hybrid queries — search semantics alongside structured filters in one SQL call
- No published head-to-head benchmarks exist from either side (as of 2026); avoid performance claims
- 90% of new daily TiDB Cloud clusters are created by AI agents (pingcap.com/compare/best-database-for-ai-agents)

**When TiDB wins:**
- Application requires ACID consistency across vector writes and relational updates (agent state management)
- Team wants one system instead of a vector store + relational DB + sync pipeline
- Real-time freshness: vectors and relational data updated in the same transaction
- SQL hybrid queries: `SELECT ... ORDER BY vec_cosine_distance(...) WHERE category = 'active'`

**When TiDB loses:**
- Pure vector workload at extreme scale (billions of vectors, no OLTP) — purpose-built vector DBs have more tuning options (HNSW parameter variants, product quantization)
- Existing deep investment in a managed vector DB (Pinecone, Weaviate Cloud) where no transactional requirements exist
- Team is comfortable with the two-system architecture and it's working reliably

**Approved language:**
- ✓ "TiDB unifies vectors, transactions, and analytics in one engine — eliminating the sync pipeline between a vector store and a relational DB"
- ✓ "HNSW-based vector indexing with SQL hybrid queries — one SQL call, no separate vector service"
- ✓ "For AI applications that need ACID consistency across agent state and vector retrieval, a unified system reduces operational complexity"
- ✗ "TiDB is a better vector database than Pinecone" (no published benchmark; legally and credibility risky)
- ✗ "Vector databases can't handle transactions" (some have limited transaction support — do not make categorical claims)
- ✗ "Vector database" as a standalone category for TiDB (TiDB is a unified system, not primarily a vector DB)

Source: pingcap.com/compare/best-vector-database

**⚠️ Gap flagged 2026-07-24:** pingcap.com/compare/best-database-for-ai-agents/ now also lists **Redis** and **Qdrant** in the AI-agent-builder competitive set (alongside Pinecone/Weaviate/Milvus/pgvector/MongoDB Atlas). No validated when-wins/when-loses/approved-language section exists yet for either — added to the buyer-type row above so they surface in competitive scans, but do not use detailed comparison claims against Redis or Qdrant until PMM validates specifics from the official compare page.

---

## MongoDB Atlas (with Vector Search + Transactions)

**TiDB's angle:** SQL ecosystem and relational scale-out; distributed ACID at MySQL-level throughput; built-in HTAP.

**When TiDB wins:**
- SQL ecosystem preference — TiDB is fully relational SQL; MongoDB's document model requires a different mental model and query language
- Scale-out of relational data with transparent sharding (MySQL-compatible, no driver changes)
- HTAP use case — MongoDB Atlas has no columnar analytics engine equivalent to TiFlash
- Complex joins on structured relational data

**When TiDB loses:**
- Document-model native applications where MongoDB's schema flexibility is genuinely the value (unstructured/semi-structured data, frequent schema evolution)
- Deep MongoDB Atlas ecosystem investment (Atlas Search, Atlas App Services, Charts, Atlas Vector Search as an integrated stack)
- Strong Node.js / JavaScript ecosystem preference where MongoDB drivers are first-class

**Approved language:**
- ✓ "TiDB offers MySQL-protocol compatible SQL with horizontal scale-out — teams running relational workloads avoid the document model migration"
- ✓ "TiDB has built-in HTAP via TiFlash; MongoDB Atlas requires external tooling for analytical queries"
- ✗ "MongoDB doesn't support transactions" (MongoDB has multi-document ACID transactions as of v4.0 — do not say this)

---

## Amazon Aurora (MySQL / PostgreSQL)

**TiDB's angle:** Distributed write scale-out + cloud-independence + built-in HTAP.

**Validated architectural difference (from official compare page):**
- Aurora uses a single-writer architecture — writes go to one primary; horizontal write scaling requires sharding or read replicas, not native distribution
- Aurora is AWS-only; TiDB runs on any cloud or on-prem (multi-cloud / cloud-independence requirement)
- Aurora has no built-in columnar analytics; requires Amazon Redshift or RDS Aurora integration for HTAP — TiDB has TiFlash built in

**Customer validation:**
- "With TiDB, we can effectively isolate workloads to prevent noisy neighbors from impacting performance." — Zander Hill, Data & Reliability Engineering (pingcap.com compare page)
- Plaid migrated 96 Aurora services to TiDB (pingcap.com/solutions/fintech)

**When TiDB wins:**
- Write throughput exceeds Aurora's single-writer capacity — TiDB's distributed writes scale horizontally
- Multi-cloud or on-prem requirement — Aurora is AWS-only
- HTAP workload — Aurora requires a separate analytics service; TiDB has TiFlash built in
- Workload isolation: TiDB prevents noisy-neighbor issues across tenants on the same cluster

**When TiDB loses:**
- AWS-native teams where Aurora's managed service simplicity and deep AWS ecosystem integration (IAM auth, CloudWatch, Parameter Groups, RDS Proxy) are the value
- Aurora Serverless v2 meets the scaling requirements without the operational model of TiDB
- Small-scale applications where Aurora's single-writer model is not a constraint

**Additional validated specifics (from PingCAP RDS landing page):**
- RDS for MySQL automatic failover for multi-region: available but with **up to 35-second delay**
- RDS for MySQL: **blocking schema changes** — making schema changes requires taking the database offline (reads available only if read replica exists)
- RDS for MySQL: **no zero-downtime upgrades** — major upgrades require manual scheduling and involve downtime; minor upgrades can involve short downtime
- RDS for MySQL: **capacity pricing** — pay hourly for base instance (RAM + CPU + storage) regardless of actual usage; TiDB Cloud Starter is usage-based

**Customer testimonials (from PingCAP RDS comparison page — real customers, unverified claims):**
- Steve (AMZTrends): "drastically lowered our costs, saving about 80%, but also offered a flexible approach to resource utilization"
- Sun (Chainbase, Data Platform Lead): "significantly cut our maintenance and hardware expenses by approximately 50%"
- Thomas Yu (KNN3 Networks, Co-founder): "not only cost-efficient and scalable but also highly conducive to development"

**Usage rule for these quotes:** These are from an internal landing page draft. Do not cite externally without verifying current approval status.

**Approved language:**
- ✓ "Aurora/RDS has a single-writer architecture; TiDB's distributed write model scales horizontally without a proxy layer"
- ✓ "Aurora is AWS-only; TiDB runs on any cloud or on-prem"
- ✓ "TiDB has TiFlash for HTAP built in; Aurora requires Redshift or a separate analytics pipeline"
- ✓ "RDS schema changes are blocking; TiDB supports non-blocking DDL"
- ✓ "RDS for MySQL major version upgrades require manual scheduling with downtime; TiDB supports zero-downtime upgrades"
- ✗ "Aurora is unreliable" (Aurora is a production-grade managed service — do not say this)
- ✗ "Aurora can't scale" (Aurora Serverless v2 scales well for many workloads — characterize specific architectural constraints)

Source: pingcap.com/compare/aurora-vs-tidb; PingCAP internal RDS landing page draft

---

## CockroachDB

**TiDB's angle:** MySQL compatibility + HTAP + lower operational complexity for MySQL-native teams.

**Validated technical differences (from official compare page):**
- **Isolation level**: CockroachDB defaults to **SERIALIZABLE** isolation. TiDB defaults to **Snapshot Isolation / REPEATABLE READ** — consistent with MySQL default behavior. For teams migrating from MySQL, TiDB's default is behaviorally closer.
- **HTAP**: CockroachDB has no built-in columnar analytics engine. TiDB has TiFlash for real-time HTAP — OLAP queries on same data as OLTP without ETL.
- **Wire protocol**: CockroachDB is PostgreSQL-compatible. TiDB is MySQL-compatible. Application rewrite scope depends on which protocol the existing system uses.

**When TiDB wins:**
- MySQL protocol compatibility is required — less application rewrite vs CockroachDB's PostgreSQL compatibility
- HTAP workload — TiFlash provides built-in columnar analytics; CockroachDB requires a separate analytics system
- Team wants MySQL-default isolation semantics (Snapshot/REPEATABLE READ) without behavior changes
- China market: TiDB has stronger community, documentation, and support presence

**When TiDB loses or ties:**
- PostgreSQL ecosystem preference — CockroachDB's PostgreSQL compatibility is a genuine strength
- SERIALIZABLE isolation is required by the application (CockroachDB enforces this by default; TiDB can be configured for SERIALIZABLE but defaults to Snapshot Isolation)
- Advanced geo-partitioning — CockroachDB's multi-region geo-partitioning features are mature and differentiated

**Approved language:**
- ✓ "TiDB's MySQL protocol compatibility means less application rewrite vs CockroachDB's PostgreSQL compatibility"
- ✓ "TiDB includes TiFlash for HTAP; CockroachDB requires a separate analytics system"
- ✓ "CockroachDB defaults to SERIALIZABLE isolation; TiDB defaults to Snapshot Isolation (MySQL-compatible REPEATABLE READ)"
- ✗ "CockroachDB is slow" (unverified; characterize specific workloads, not the product)
- ✗ "CockroachDB doesn't support HTAP" (correct fact, but say it as a comparison, not an attack)

Source: pingcap.com/compare/cockroachdb-vs-tidb

---

## YugabyteDB

**TiDB's angle:** MySQL compatibility + HTAP + range-based sharding for scan-heavy workloads.

**Validated technical differences (from official compare page):**
- **Sharding default**: YugabyteDB uses hash-based sharding by default. Range scans over ordered data (e.g., time-series, sequential IDs) can be less efficient than with range-based sharding. TiDB uses range-based sharding which handles ordered scans naturally.
- **HTAP**: YugabyteDB has no built-in columnar analytics engine. TiDB has TiFlash.
- **Wire protocol**: YugabyteDB supports both PostgreSQL (YSQL) and Cassandra-compatible (YCQL) protocols; PostgreSQL compatibility has documented incompatibilities. TiDB is MySQL-compatible.

**When TiDB wins:**
- MySQL protocol compatibility is required
- Workloads with heavy range scans (time-series, ordered access patterns) — TiDB's range-based sharding is a better fit
- HTAP workload — TiFlash provides built-in OLAP; YugabyteDB is OLTP-only
- Mature Kubernetes operator (TiDB Operator is CNCF ecosystem; TiKV is a CNCF graduated project)

**When TiDB loses or ties:**
- PostgreSQL ecosystem preference — YugabyteDB's YSQL layer is a genuine PostgreSQL-compatible option
- Cassandra-compatible API requirement (YCQL) — TiDB has no equivalent
- YugabyteDB has been around since 2017 with a strong open-source community; do not underestimate adoption

**Approved language:**
- ✓ "TiDB includes TiFlash for HTAP; YugabyteDB is OLTP-only and requires a separate analytics system"
- ✓ "YugabyteDB defaults to hash-based sharding; TiDB uses range-based sharding — relevant for range scan-heavy workloads"
- ✓ "TiDB is MySQL-compatible; YugabyteDB's YSQL is PostgreSQL-compatible with documented incompatibilities"
- ✗ "YugabyteDB can't scale" (it is designed for distributed scale — characterize specific capability gaps)

Source: pingcap.com/compare/yugabytedb-vs-tidb

---

## Snowflake / ClickHouse (analytical databases)

**TiDB's angle:** Real-time freshness + unified OLTP+OLAP = eliminate ETL. TiDB is not a data warehouse replacement — it is the choice when OLTP and OLAP need to coexist on live data.

**When TiDB wins:**
- Customer needs OLTP + analytics in one system — eliminate ETL pipeline and the operational complexity of maintaining two synchronized systems
- Real-time data freshness: TiFlash reads from the same data as TiKV with typically sub-second to few-second replication lag; Snowflake requires a load pipeline (minutes to hours)
- ACID consistency on the analytics layer — TiDB guarantees consistent snapshots; Snowflake reflects the state at load time

**When TiDB loses:**
- Pure analytics workload with no transactional requirements — Snowflake and ClickHouse are purpose-built and outperform TiFlash on complex analytical queries at petabyte scale
- Rich BI / analytics ecosystem: Snowflake's ecosystem (dbt, Looker, Fivetran, Tableau connectors) is significantly richer
- Extreme analytical scale: ClickHouse outperforms TiFlash on very high-cardinality aggregations and raw scan throughput
- Existing Snowflake/ClickHouse investment for pure analytics is working and OLAP-only

**Approved language:**
- ✓ "TiDB's TiFlash serves OLAP queries on the same data as OLTP writes — no ETL pipeline, typically sub-second to few-second replication lag"
- ✓ "For workloads that need both transactional integrity and fresh analytics, TiDB eliminates the two-system architecture"
- ✗ "TiDB replaces Snowflake" (for pure warehousing at petabyte scale, this is not accurate)
- ✗ "Real-time analytics" without disclosing TiFlash replication lag (always state: "typically sub-second to few-second lag from TiKV write to TiFlash availability")

---

## Neon (now part of Databricks)

**TiDB's angle:** Unified stack (OLTP + analytics + AI in one) vs. Neon's deliberate fragmentation (Neon for TP → Databricks for AP → separate vector for AI).

**Validated architectural differences (from internal PingCAP competitive doc):**
- **Scalability**: Neon uses vertical scaling only; write throughput is limited by single primary node capacity. TiDB scales horizontally for both reads and writes.
- **Analytics**: Neon's analytics path requires ETL to Databricks or external warehouse — no in-platform analytics engine. TiDB has TiFlash built in.
- **Vector search**: Neon has standard pgvector (limited to single-node scale). TiDB has distributed vector search.
- **Ownership**: Neon is now part of Databricks — customers are increasingly locked into the Databricks ecosystem. TiDB is vendor-neutral, Apache 2.0.
- **Deployment**: Neon is serverless-only on AWS and Azure; no self-managed option. TiDB supports multi-cloud, BYOC, on-prem.
- **HA**: Neon has standard cloud HA with potential downtime/latency during failovers. TiDB uses Raft-based consensus with Zero RPO for multi-region DR.

**Database Branching for Agent Sandboxing (TiDB differentiator):**
TiDB's database branching enables agents to safely simulate actions, validate generated SQL, and run "what-if" scenarios in isolated environments without risking production data. This is specifically relevant for AI agent workloads — Neon does not offer equivalent agentic sandboxing at scale.

**The core framing (from PingCAP internal doc):**
> "Neon's Model: Fragmented Stack. You use Neon for TP, Databricks for AP, and Pinecone for Vector. You glue them together with ETL. Good for small apps, bad for complexity. TiDB's Model: Unified Stack. You get TP, AP, and Vector in one scalable engine. No ETL, real-time freshness, lower TCO for growth."

**When TiDB wins:**
- Need unified OLTP + analytics + AI workloads without ETL pipelines
- Workloads requiring horizontal write scale-out beyond single-node limits
- Multi-cloud, BYOC, or on-prem deployment requirements
- Enterprise compliance and self-managed requirements
- AI agent workloads with dynamic cluster/branch creation
- MySQL compatibility requirement (TiDB = MySQL-compatible; Neon = PostgreSQL-compatible)

**When TiDB loses:**
- Small Postgres app with low ops requirements — Neon is excellent here
- Already committed to the Databricks ecosystem for analytics and ML
- OLTP-only workloads with no analytics or AI plans
- Developer-experience-first teams that value Neon's instant branching for CI/dev workflows

**Approved language:**
- ✓ "TiDB handles OLTP, analytics, and vector search in one engine — Neon requires ETL to Databricks for analytics and separate tools for vector"
- ✓ "Neon is now part of Databricks; teams adopting Neon are increasingly tied to the Databricks roadmap and pricing"
- ✓ "TiDB's horizontal write scaling handles growth beyond Neon's single-writer limit"
- ✓ "TiDB's database branching enables agent sandboxing — isolated environments for experiments or tenants without risking production"
- ✗ "Neon isn't production-ready" (it is production-ready for its target scale and Postgres use cases)
- ✗ Characterize Neon's Databricks acquisition as a weakness without framing it as a buyer's choice (some teams want the Databricks stack)

Source: PingCAP internal competitive document (TiDB vs. Neon) — not independently verified; use for internal messaging alignment

---

## PlanetScale

**TiDB's angle:** True serverless autoscaling at all tiers vs. PlanetScale's autoscaling gated behind $3k/mo enterprise plans.

**Validated architectural differences (from PingCAP blog draft):**
- PlanetScale is powered by Vitess (MySQL sharding layer); TiDB is a native distributed database
- **Scaling**: PlanetScale non-enterprise plans require reserving RAM/CPU upfront; automatic horizontal scaling is enterprise-only ($3,000/mo+); scale-to-zero: No. TiDB Cloud Starter scales seamlessly on demand, scales to zero.
- **Multi-region**: PlanetScale reserves multi-region for enterprise customers. TiDB Cloud Starter includes multi-region.
- **Vector search**: PlanetScale has no vector search. TiDB has native vector search.
- **AI-assisted SQL editor**: PlanetScale: No. TiDB: Yes.
- **Free tier**: PlanetScale: No. TiDB Cloud Starter: Yes (25 GiB free storage).
- Both have: ACID transactions, non-blocking schema changes, database branching, MySQL compatibility.

**When TiDB wins:**
- Need autoscaling without enterprise pricing commitment (PlanetScale auto-scaling starts at $3k/mo)
- Need multi-region without enterprise tier
- AI workloads: vector search and AI-assisted query editing
- Prefer usage-based pricing vs. reserving capacity upfront
- Want a free tier for development

**When TiDB loses:**
- PlanetScale's non-blocking schema migration tooling (with schema rollbacks) is a genuine developer experience win for schema-heavy development workflows
- Deep investment in PlanetScale's Vitess-based architecture and operations
- Strong JavaScript/Node.js preference — PlanetScale has a dedicated serverless JS driver

**Approved language:**
- ✓ "PlanetScale's auto-scaling and multi-region require enterprise plans starting at $3,000/mo; TiDB Cloud Starter includes autoscaling and scales to zero on the free tier"
- ✓ "TiDB Cloud Starter has vector search and AI-assisted SQL; PlanetScale has neither"
- ✓ "Both have non-blocking schema changes and database branching — PlanetScale's schema rollback tooling is specifically well-regarded"
- ✗ "PlanetScale can't scale" (enterprise plans do scale; characterize the pricing gate, not a technical limitation)

Source: PingCAP internal blog draft (TiDB Serverless vs. PlanetScale) — note: uses old "TiDB Serverless" name (now "TiDB Cloud Starter")

---

## Supabase

**TiDB's angle:** Production-grade distributed SQL vs. developer-friendly BaaS. These products serve different needs — the comparison surfaces when a team outgrows Supabase and needs distributed scale, HTAP, or AI workloads at scale.

**Critical distinction:** Supabase is a Backend-as-a-Service (BaaS), not just a database. It includes Auth, Storage, REST/GraphQL auto-generation, Edge Functions, and a dashboard. TiDB does not have these application-layer features. If a team needs the full BaaS stack, Supabase wins on developer experience.

**Validated architectural differences (from PingCAP internal competitive doc):**
- **Database core**: Supabase wraps single-node PostgreSQL with optional read replicas; vertical scaling only. TiDB is horizontally scalable distributed SQL.
- **Analytics**: Supabase requires external warehouse (BigQuery, Snowflake, or ClickHouse) for analytics. TiDB has TiFlash built in.
- **Vector search**: Supabase uses pgvector (limited performance at scale). TiDB has built-in native vector index.
- **Deployment**: Supabase: hosted on Supabase Cloud only (no BYOC, no self-managed). TiDB: AWS/GCP/Azure/BYOC/on-prem.
- **Compliance**: Supabase has SOC 2 Type 2 + HIPAA (with BAA). TiDB BYOC/on-prem enables SOC 1/2/3, ISO 27001/27701, GDPR, HIPAA-like environments.
- **Lock-in**: Supabase's Auth, Storage, Realtime API, and Edge Functions are not portable — migrating off requires rewriting application layers. TiDB is Apache 2.0, portable across clouds.
- Tier naming confirmation: Supabase internal doc refers to "Starter (old Serverless)" — confirms "TiDB Cloud Starter" is the correct current name.

**When TiDB wins:**
- Need distributed write scale-out beyond single-node Postgres limits
- HTAP / real-time analytics without ETL pipelines
- AI agent workloads requiring distributed vector search at scale
- Enterprise compliance with BYOC or on-prem deployment requirement
- Multi-tenant SaaS at high tenant counts (>100 customers needing isolation)
- Prefer open-source (Apache 2.0) with minimal platform lock-in

**When TiDB loses:**
- Team needs a full BaaS stack: Auth, Storage, REST/GraphQL APIs, Edge Functions — Supabase bundles all of these; TiDB is database-only
- MVP / early-stage development where Supabase's rapid scaffolding is the value
- PostgreSQL ecosystem is preferred and pgvector scale requirements are manageable
- Small/medium scale where Supabase's managed Postgres is sufficient

**Approved language:**
- ✓ "Supabase is a full-stack BaaS — it bundles Auth, Storage, and APIs around Postgres. TiDB is a database only; teams that need the full BaaS stack should use Supabase for small/medium scale"
- ✓ "When a Supabase-built product outgrows single-node Postgres, TiDB Cloud Starter provides the same free-tier entry with a path to distributed scale without a full migration"
- ✓ "Supabase requires external services for analytics (BigQuery, Snowflake) and has limited vector search at scale; TiDB has both built in"
- ✗ "Supabase isn't production-ready" (it is production-ready for its target scale and use cases)
- ✗ Compare TiDB to Supabase on Auth, Storage, or Edge Functions — TiDB doesn't have these; the comparison is database capabilities only

Source: PingCAP internal competitive document (TiDB vs. Supabase) — not independently verified; use for internal messaging alignment

---

## MySQL / RDS MySQL (scale-out migration)

**TiDB's angle:** MySQL-protocol compatible horizontal scale-out — the upgrade path when a single MySQL instance hits its limits.

**Validated metrics (from official compare page):**
- 52–67% infrastructure cost savings vs RDS MySQL at 8,000 QPS / 500GB dataset / aws-us-east-1 (pingcap.com/solutions/lower-infrastructure-costs)
- Up to 500TB per cluster; 2 million QPS at millisecond latencies (pingcap.com)
- 4,000+ global enterprises use TiDB (pingcap.com/compare/mysql-vs-tidb)

**When TiDB wins:**
- Single MySQL instance has hit write throughput, storage, or connection limits
- HTAP requirement: run analytics on live transactional data without ETL
- Multi-region or high-availability requirements beyond MySQL replication
- Team wants MySQL protocol compatibility — minimal application changes

**When TiDB loses:**
- MySQL is working fine: if scale and availability requirements are met, MySQL is simpler and cheaper
- Simple read-heavy workloads with read replicas: MySQL + read replicas may be sufficient
- AWS-only teams who prefer RDS MySQL with Aurora read replicas in the AWS ecosystem

**Approved language:**
- ✓ "TiDB is MySQL protocol compatible — migrate without rewriting your application; validate in POC against the compatibility docs"
- ✓ "52–67% infrastructure cost savings vs RDS MySQL at 8,000 QPS / 500GB on aws-us-east-1" (cite source: pingcap.com/solutions/lower-infrastructure-costs)
- ✓ "TiDB is the horizontal scale-out path for MySQL — when your single instance hits its limits"
- ✗ "Fully MySQL compatible" (documented incompatibilities exist — always say "MySQL protocol compatible" and link to compatibility docs)
- ✗ Quote cost savings without workload context (always specify QPS, dataset size, and region)

Source: pingcap.com/compare/mysql-vs-tidb, pingcap.com/solutions/lower-infrastructure-costs

---

## SaaS databases positioning (multi-tenant context)

**TiDB's claimed position (from official page):**
> "The only option that combines distributed SQL architecture, MySQL wire compatibility, native HTAP analytics, and first-class Kubernetes operability in a single system."

Source: pingcap.com/compare/best-databases-for-saas

**Usage rule:** This claim is from an official PingCAP compare page. Use it in SaaS competitive contexts, but verify it is still current before citing publicly.

**Core SaaS capability claims:**
- Workload isolation: prevents noisy-neighbor issues across tenants on the same cluster
- Resource quotas: per-tenant compute and storage limits without per-tenant clusters
- Database branching: tenant environment isolation for dev/test
- Atlassian: consolidated 750+ Postgres clusters to 16 TiDB clusters (public proof point)

---

## Siloed stack: RDS + ClickHouse + Elasticsearch

**TiDB's angle:** Unified architecture vs. "accidental complexity" — teams typically build this three-system stack incrementally (start with RDS, add ES for search, add ClickHouse for analytics) and end up with significant integration overhead.

**The architecture comparison (from PingCAP internal doc):**

| Dimension | TiDB | RDS + CH + ES |
|-----------|------|--------------|
| Philosophy | Single platform for OLTP + OLAP + search | Three specialized silos requiring integration |
| Data storage | Unified; logical data replicated via Raft | Same data stored 3+ times with different schemas (Row + Column + Inverted Index) |
| ETL | Zero-ETL within the database | Critical dependency — Kafka/Debezium/Airflow CDC connectors required |
| Consistency | Strong (ACID) across all workloads | Eventual — analytics/search lag behind RDS due to ETL pipeline latency |
| Query routing | Hybrid scan: one SQL query accesses Row + Column stores automatically | Application-level: developers must query the correct DB and manually join results |
| AI/Vector | Native vector + full-text search | Elasticsearch for search, but isolated from transactional source of truth — complicates RAG |

**TiDB also has built-in full-text search**, reducing the need for a separate Elasticsearch cluster for standard search use cases.

**Where the siloed stack still wins:**
- **Extreme log aggregation**: Purely non-transactional log ingestion at petabyte scale with unstructured text → Elasticsearch/ELK is purpose-built
- **Static immutable data analysis**: Immutable historical data requiring complex statistical functions unique to ClickHouse → ClickHouse as standalone data warehouse may outperform TiFlash

**Choose TiDB over the siloed stack when:**
- Need to scale OLTP beyond a single MySQL/Postgres instance
- Want real-time analytics on fresh data without ETL pipelines
- Want to simplify the stack (one cluster vs. three) and reduce "Integration Tax"
- Need hybrid scan: join current orders (OLTP) with historical trends (OLAP) in one SQL query
- Building AI agents that need to read/write data in real-time without waiting for pipeline syncs

**Choose siloed stack when:**
- Purely unstructured log search at petabyte scale (Elasticsearch specialized)
- Static, immutable historical data only (ClickHouse standalone)
- Legacy system with no engineering capacity to consolidate architecture

Source: PingCAP internal competitive document (TiDB vs. RDS + ClickHouse + Elasticsearch) — internal framing; use for positioning, not external claims

---

## Prohibited competitive behaviors

- Do not present competitor weaknesses without citation from the competitor's own documentation or a widely acknowledged public limitation
- Do not benchmark against competitors without full methodology disclosure (see `tidb-benchmark-narrative`)
- Do not use competitors' names in ad copy or SEO targeting without legal review
- Do not make "we're faster than [competitor]" claims without a specific, reproduced benchmark with full methodology
- Do not claim isolation-level equivalence without disclosure: TiDB defaults to Snapshot Isolation (REPEATABLE READ); some workloads expecting SERIALIZABLE semantics must be informed of this
- China market: avoid competitive comparisons involving Chinese cloud providers' database products without specific legal/BD clearance
- Any claim sourced from a PingCAP compare page should be treated as PingCAP's framing — not independently verified; use for internal messaging alignment, flag for legal review before using in paid media or analyst briefings