Database Selection Guide: Decision Framework for New Projects with Xinchuang Options

Introduction

"Which database for a new project" has no standard answer, but it does have a standard decision process. This article breaks down mainstream options by applicability boundaries, provides a decision tree, and emphasizes Xinchuang (domestic Chinese) database selection.

Core principle: The first constraint in selection is not technology but team familiarity — a database no one has maintained, no matter how advanced, becomes a liability.

Four Decision Questions

Data shape: Strongly relational tables (users-orders-payments) vs flexible documents (product attributes/content).

Consistency requirement: Financial inventory demands strong consistency; browse logs can tolerate eventual consistency.

Scale and growth: Millions of rows — MySQL single instance handles easily; billions — consider distributed.

Team and operations: Unfamiliar databases are technical debt regardless of features.

Relational Database Comparison

MySQL

Positioning: Internet default choice.

Strengths: Mature ecosystem, operations tooling, abundant talent.

Weaknesses: Weak complex query optimizer, narrower feature set.

PostgreSQL / Kingbase (金仓)

Positioning: Most feature-rich open-source relational DB; Kingbase is Xinchuang variant based on PG kernel.

Strengths: JSON, arrays, GIS, CTEs, window functions.

Weaknesses: One process per connection, VACUUM maintenance overhead.

Oracle / Dameng (达梦)

Positioning: Traditional enterprise / Xinchuang; Dameng compatible with Oracle syntax.

Strengths: Large-scale OLTP, stored procedures, Dameng Xinchuang compliance.

Weaknesses: Expensive commercial licensing; Dameng compatibility mode pitfalls.

Migration notes: MySQL → Kingbase: watch PG dialect (case sensitivity, sequences, transaction behavior). Oracle → Dameng: verify stored procedures and pagination dialect.

MongoDB vs Redis Boundaries

MongoDB (Document Model)

Suitable for: Highly variable fields (multi-spec products), nested structures, rapid iteration without fixed schema.

Unsuitable for: Multi-document strong transactions (4.0+ supports but high performance cost), complex JOINs, strongly relational data.

Rule of thumb: Data with relationships and foreign-key semantics → relational; self-contained single entity → MongoDB optional.

Redis (Cache & Specific Structures)

Not a "store" but a "high-speed data structure service": caching, sessions, distributed locks, leaderboards (ZSet), counters.

Warning: Data safety inherently weaker than relational DBs; core data must reside in relational DB, Redis as acceleration layer.

NewSQL / Distributed Databases

TiDB: MySQL-compatible distributed HTAP. Consider when single table reaches billions and sharding becomes unmanageable.

OceanBase: Financial-grade distributed OLTP. Consider for ultra-high concurrency strong consistency + Xinchuang requirements.

openGauss: Huawei-led open source, Xinchuang PG-family. Consider for Huawei ecosystem / Xinchuang.

Common prerequisite: Scale has arrived (single MySQL instance cannot cope) and dedicated DBA exists. Small-to-medium systems adopting distributed DB = trading distributed complexity for scale not yet needed.

Decision Tree

Is data structured with multi-entity relationships?
├─ Yes → Relational
│   ├─ Xinchuang required?
│   │   ├─ Oracle legacy → Dameng (minimal migration effort)
│   │   └─ New build / PG ecosystem → Kingbase / openGauss
│   ├─ General internet business → MySQL 8.0 (optimal talent/ops cost)
│   └─ Heavy complex queries / GIS / JSON → PostgreSQL
├─ No (self-contained documents, volatile schema) → MongoDB
└─ High-speed small data (cache/session/leaderboard) → Redis

Scale corrections:
- Single table >10M rows → read-write separation / archiving first, then evaluate sharding
- Sharding still insufficient / HTAP needed → TiDB / OceanBase

Typical Combination (End-state for Most Systems)

MySQL / Kingbase (core business data)
+ Redis (cache, session, locks)
+ MongoDB (content/log non-core data, as needed)
+ ES (add when search requirements appear)

Writing a Selection Document (Review-Ready Approach)

A selection report is not a feature checklist but an answer to doubts:

Candidate list: At least 2-3 candidates with explicit elimination reasons (not "never heard of").

Scenario matching: Use real project data model and volume to stress-test key scenarios (POC).

Operations ledger: Backup/recovery drills performed? Monitoring/alerting? Community/commercial support channels?

Exit cost: How to migrate data out? (Beware lock-in to proprietary formats.)

Team ledger: Current team familiarity, hiring market talent supply.

Review passes on POC evidence + clear exit cost, not on how pretty the feature checklist looks.

Quick Summary

Four questions: data shape → consistency → scale → team familiarity; familiarity is the first constraint .

Relational defaults: Internet → MySQL; Xinchuang → Dameng (Oracle legacy) or Kingbase (PG family); Feature-heavy → PostgreSQL.

MongoDB for self-contained documents; Redis is acceleration layer, not foundation; Distributed DB only at real scale.

Xinchuang migration: MySQL→Kingbase mind PG dialect; Oracle→Dameng verify stored procedures.

Selection report core = POC benchmarks + ops/exit costs, not feature ticks.

Common end-state: Relational DB + Redis + (optional) Mongo/ES — don't stack the full suite upfront.

Insight: Choosing a database isn't about picking the "strongest", but the one your team can keep alive. The most expensive technical debt is adopting a database nobody knows how to operate.