CockroachDB

Each feature = what it is + why it's genuinely strong + the edge-case truth.

1. Cross-region / cross-cloud strongly consistent distributed SQL (multi-active access) Why it's genuinely strong: nodes in every region can serve SQL; each Range's leaseholder is distributed by load/region; with REGIONAL BY ROW, row-level data sits next to the region that accesses it; SURVIVE ZONE/REGION FAILURE declaratively expresses disaster-recovery goals. Edge-case truth: multi-active means "multi-active access," not "writes complete locally." Cross-region writes still wait for the Raft quorum / consensus of every Range touched; SURVIVE REGION FAILURE writes "at least one cross-region RTT" into every write's latency budget on every healthy day. In selection, "disaster-recovery goal" must be translated into "latency budget."
2. ACID across nodes with Serializable by default Why it's genuinely strong: MVCC + HLC (no TrueTime dedicated hardware needed) + write intents + cross-Range 2PC + Parallel Commits (~1 RTT commit); the default isolation level is the strongest one; passing the 2021 Jepsen report is a hard endorsement of its correctness reputation. Edge-case truth: Serializable's price is that under hot contention, 40001 / restart-transaction is thrown to the application — retry logic is the application's tax, not the database's; HLC's price is the clock-uncertainty window and strict NTP operations — nodes protect themselves when clock skew exceeds the threshold (third-party materials say the default is ~500ms, pending official verification). Reading "strongest by default" as "zero cognitive load by default" is a misreading.
3. Automatic Range split / merge / rebalance (no manual sharding) Why it's genuinely strong: the KV keyspace is sharded into Ranges; oversized Ranges split automatically (third parties say ~512MB, pending verification of the v26.3 default); load-based splits can split by QPS; small Ranges merge (the merge queue works with split heuristics to avoid flapping); Ranges move automatically when nodes are added or removed. The application layer can largely say goodbye to sharding. Edge-case truth: splitting cures "large data volume," not "single hot key." Sequential auto-increment primary keys pin all writes to a single Range/leaseholder — most nodes sit idle on CPU while total throughput is capped. This is CockroachDB's most classic "plenty of strength but nowhere to apply it" scene. UUID / hash-sharded indexes can scatter the load but sacrifice sequential-scan locality.
4. PostgreSQL wire-protocol ecosystem access Why it's genuinely strong: PG drivers/ORMs like psycopg2, SQLAlchemy, Prisma, Hibernate, ActiveRecord basically connect directly (port 26257), so the "interface cost" of migration is low. Edge-case truth: protocol compatibility ≠ behavior compatibility. Session-scoped advisory locks are unsupported (apps that depend on them, like Authentik, won't run — the upstream issue was still open as of 2026-06), plus no triggers/stored procedures (PL/pgSQL), no FDW, no LISTEN/NOTIFY, no SEQUENCE (use UUID/unique_rowid()). Storj's historical migration (v19.2 era) took one full-time developer-month to handle compatibility differences — pgwire saves you "rewriting the connection layer," not "zero migration cost."
5. Declarative multi-region data placement (REGIONAL BY ROW / GLOBAL) Why it's genuinely strong: row-level region affinity + GLOBAL tables (read-heavy reference data replicated in every region) is one of the most complete data-placement abstractions for the "one global table" scenario; follower reads let far-region reads use local replicas and skip the WAN. Edge-case truth: GLOBAL table writes go through the home region — do the write-amplification math; REGIONAL BY ROW requires "region" to be modeled into the primary/partition key at schema-design time — retrofitting later means redoing the data model; follower reads are bounded-staleness reads — reading stale data is a feature, not a bug — used in the wrong place it's a production incident.

Deep Water 1 (Storage Engine): Range splits save you from data volume, not from a single hot key

• Mechanism: when a Range exceeds capacity/load thresholds, the leaseholder picks a split key and initiates the split via Raft; the merge queue periodically scans Ranges for which the local store holds the lease, composes a hypothetical merged Range with the right neighbor, and skips the merge if the split queue would immediately split it again (natural anti-flapping); small Ranges (default <8MB threshold for exclusion from merge consideration, configurable per zone) merge.
• At the edge: sequential auto-increment primary keys → all new writes land on the rightmost Range → that Range's leaseholder becomes a single-point write bottleneck; Range splitting does nothing for a "single hot key" (a hot key still belongs to exactly one Range); at this point cluster CPU is largely idle but write throughput is capped — only Hot Ranges / SHOW RANGES can pinpoint it. Mitigation relies on UUID primary keys or hash-sharded indexes, at the cost of turning range scans into scatter-gather.
• Selection implication: any MySQL/PG migration with a "global auto-increment ID" habit must change its primary-key strategy first; hotspot load tests must use the real key distribution, not just uniform benchmarks.
• Sources: official range-merges tech note, design.md; community ops summary (sanoy24); HN historical discussion (2019, historical community observation)

Deep Water 2 (Replication & Consistency): The leaseholder is the baton of latency; follower reads are stale reads

• Mechanism: strong reads go through the leaseholder (local reads, no Raft needed); writes are proposed by the leaseholder and confirmed by a Raft quorum; follower reads use the closed timestamp to let follower replicas serve bounded-staleness reads, avoiding WAN hops and leaseholder hotspots (but they don't fix "single hot write key").
• At the edge: in a cross-region deployment, if a Range's leaseholder sits in a far region, every strong read/write pays one WAN RTT; SURVIVE REGION FAILURE requires cross-region consensus, so the write-latency floor = the round trip to the nearest required replica. When a node fails, lease re-election has a seconds-level window (third-party notes say ~4.5s heartbeat-timeout scale, pending official verification) during which writes to the affected Ranges are unavailable — that's normal behavior for a CP system, not a bug.
• Selection implication: a multi-region design must answer "where is the leaseholder" and "can reads tolerate staleness"; latency SLAs must be signed against "real-topology measurements," not "single-region benchmarks."
• Sources: official follower reads RFC (2020), non-blocking txns proposal; Cockroach Labs official skills (multi-region); Medium third-party analysis (2026-08)

Deep Water 3 (Transactions & Time): Parallel Commits compresses RTT count, not physics; HLC's tax is clocks

• Mechanism: cross-Range transactions use 2PC; Parallel Commits folds "write intents (1 RTT) + commit transaction record (1 RTT)" together, letting the transaction confirm the commit to the client after the first phase — critical path ~1 RTT; HLC = physical clock + logical counter, replacing TrueTime hardware with an uncertainty window.
• At the edge: ① In a single region, 2 RTTs → 1 RTT is a genuine latency halving; for cross-ocean transactions 1 RTT is still 100–300ms scale (third-party estimate — measure your own topology); Parallel Commits doesn't eliminate geography. ② When clock skew exceeds max-offset (third parties say the default is 500ms, pending official verification), the node protects itself / refuses service — NTP is a production prerequisite, and VM clock drift is an invisible killer. ③ Under high contention, transactions get restarted inside the uncertainty window; the application sees 40001; retries must be done by the application, and "retrying external side effects" (sending email, calling payment) is the application's own pit — the database only guarantees that "work inside the database is redoable."
• Selection implication: a transaction-model POC must include "cross-region transaction latency distribution" and "hotspot-conflict retry rate"; any code that does external calls before commit must be rewritten on migration.
• Sources: official design docs; third-party engineering handbook (max-offset); Medium 2026-08 analysis (PG vs CRDB regional failure)

Deep Water 4 (SQL Layer / Compatibility): pgwire is "dialect compatibility"; the gap list is the migration's true workload

• Mechanism: a self-built SQL layer implements PG wire protocol v3 + most PG syntax — not a PG kernel fork.
• At the edge (v26.3 official compatibility docs list explicit gaps): range types, events, drop primary key, XML functions, column-level privileges, XA, template databases, FDW, session-scoped advisory locks are unsupported. Also: SERIAL behavior differences, default INT8, automatic rowid primary keys, missing extension ecosystem (PostGIS, etc.), pg_stat_statements unavailable (monitoring-toolchain migration gap). Historical cases: Storj's migration took ~1 person-month handling compatibility/migration scripts (v19.2 era, historical reference only); Authentik can't run directly due to session advisory locks (upstream issue still open as of 2026-06).
• Selection implication: a PG migration must run the compatibility matrix item by item, especially triggers, stored procedures, advisory locks, FDW, extensions; "Django/Rails runs" does not mean "your PG runs."
• Sources: official postgresql-compatibility (v26.3); community migration cases

Deep Water 5 (Operations / Upgrades): the release train is fast; finalize is a one-way street

• Mechanism: rolling upgrades proceed node by node; after all nodes swap binaries, explicitly SET CLUSTER SETTING version to finalize; before finalize you can keep the rollback option via cluster.preserve_downgrade_option; after finalize there is no rollback.
• At the edge: multiple majors per year (v25.4 → v26.1 → v26.2 → v26.3) make upgrades "routine operations," not "annual projects" — teams that can't keep up get stuck on old majors for a long time; after finalize, problems can only be fixed forward, never rolled back — so upgrades need a full backup + (forward) rollback plan. Certificate management is a standing complaint (community ops handbooks have a dedicated "expired certificates require full re-issuance + restart" procedure).
• Selection implication: write "upgrade drills" into the SLA and certificate rotation into the on-call runbook; Cloud Basic auto-tracks new stable versions (third-party statement, pending official verification) — pinning a version depends on Standard/Advanced capability boundaries.
• Sources: community ops handbooks (rolling-upgrade practice); Rancher helm chart docs (preserve_downgrade_option)

Deep Water 6 (Cost / Licensing): the license changed three times in three years; 2026's source-going-private is the watershed

• Mechanism: Apache 2.0 (2017–2019) → BSL (2019–2024, restricted competitive DBaaS, old versions revert to Apache on expiry) → CockroachDB Software License (2024–present, free Enterprise under $10M revenue) → 2026: new versions developed in a private repo, public repo keeps only historical snapshots.
• At the edge: "self-hostable" ≠ "self-controllable." In the BSL era you could at least read the source and it reverted to Apache on expiry; after 2026 there is no source to read for new versions and no community path to submit core PRs — when you hit a kernel-level bug in production, your only options are "wait for the vendor to fix it / buy support," exactly like a closed-source commercial database. Revenue definitions (affiliated companies, the $10M line), usage restrictions, and audit clauses must be read word by word in the contract — don't rely on blog headlines.
• Selection implication: treat CockroachDB as a "commercial database" for TCO and exit-planning; teams that need source-level self-remediation (regulatory/strong-compliance scenarios) hit a hard barrier here.
• Sources: official blog (licensing-update-2024, source-code-protection 2026); SDTimes, The Register coverage

Deep Water 7 (Cost / Billing): RU is abstract currency; cross-region replication is a hidden tax

• Mechanism: Cloud bills by RU (Request Units) + storage; RU abstracts CPU/IO/network into a single currency.
• At the edge: RU abstraction makes budgets hard to predict — the same SQL costs more RU with a wrong index choice, cross-Range fan-out, or cross-region traffic; multi-region writes pay three times over in "compute + network + storage"; self-hosting dodges RU, but starts at 3 nodes + cross-AZ traffic + commercial license/ops headcount. Third-party 2024 prices are already historical; 2026 current prices follow official figures — don't budget on old numbers before getting a quote.
• Selection implication: the POC must run a "billing shadow test" (run the same workload on Cloud for a week and look at the bill), not just performance; self-hosted vs Cloud TCO must be computed over 3 years, headcount included.
• Sources: TechTarget 2024 (historical pricing); 2026 third-party deployment guide (Basic $15 benefit/50M RU/10GiB, pending official verification)

Deep Water 8 (Storage / Performance): the debt of LSM + MVCC — tombstones, GC, and fan-out

• Mechanism: Pebble (RocksDB-family LSM) underneath, with MVCC multi-versions on top; Range splits/merges and rebalances are all background data movement.
• At the edge: heavy UPDATE/DELETE produces tombstones and old versions; when GC/compaction can't keep up, read amplification, rising disk watermarks, and p99 latency spikes follow; one SQL scanning many Ranges triggers DistSQL fan-out, amplifying network and memory; "deleted everything but the disk didn't shrink and queries got slower" is a recurring community ops scene (2019 HN discussion, historical observation). Long transactions/long reads pin MVCC versions and slow GC — "one forgotten-open transaction dragging down whole-cluster GC" is no legend.
• Selection implication: bulk deletes/updates need batched execution + SOPs for watching compaction/GC watermarks; slow-query triage should first ask "how many Ranges did it scan."
• Sources: community ops summaries; HN historical discussion; official design docs

1. Correctness reputation (Jepsen endorsement + Serializable by default) Why it's real: the 2021 Jepsen test pass + the strongest isolation level by default — for finance/ledger teams who rank "don't get it wrong" first, this is an architecture-level trust credential. Edge and limits: correctness is paid for with latency (Raft consensus) and retries (40001); Jepsen 2021 was 5 years ago and more than a dozen major versions back — the reputation needs continuous validation from new versions to stay current. Sources: jepsen.io report (third-party, 2021); community consensus. Observed version: v21.x-era report; v26.3 status pending new evidence
2. Multi-region / global deployment is genuinely strong Why it's real: REGIONAL BY ROW + survival goals + follower reads form a complete multi-active primitive set, not a "primary-replica + middleware" patchwork; third-party 2026 measured commits of eu-west 5ms / ap-south 7ms show row-level region affinity can genuinely get latency into single-digit milliseconds. Edge and limits: single-digit milliseconds belong only to workloads where "data and people are aligned by region"; cross-region writes to the same row/transaction still pay the WAN tax; GLOBAL table write amplification needs its own accounting. Sources: Medium third-party engineering analysis (2026-08); official skills. Observed version: v26.x
3. Elastic scaling: add nodes, never shard Why it's real: Ranges split/move automatically; scaling out is an online operation invisible to the application — this is the most concrete payoff of the word "distributed." Edge and limits: data movement during scale-out eats IO/network — scaling at peak is like changing engines mid-flight; and most workloads won't fill 3 nodes in 3 years — paying the ops tax for scalability you'll never use is a common misuse. Sources: community consensus + official docs. Observed version: all versions
4. Low friction into the PG ecosystem Why it's real: wire-protocol compatibility lets existing PG drivers/ORMs/toolchains (psycopg2, SQLAlchemy, Hibernate…) connect directly; the team's learning curve is gentle. Edge and limits: see Deep Water 4 — it saves the connection-layer rewrite, not zero migration; pg_stat_statements being unavailable means the existing PG monitoring/slow-query toolchain has to be replaced. Sources: official compatibility docs (v26.3); Storj historical migration case. Observed version: v26.3
5. Native CDC (Changefeed) is data-engineering friendly Why it's real: CREATE CHANGEFEED INTO 'kafka://...' goes natively into Kafka — no Debezium/JVM/replication slots; resolved timestamps let downstream (Iceberg/Delta/Snowflake) turn at-least-once into exactly-once ingestion; schema evolution is automatic under Avro mode. Edge and limits: enterprise-grade CDC is mostly behind the paywall; at-least-once semantics require downstream idempotency/dedup design; changefeed latency and overhead for large transactions need their own load testing. Sources: Medium third-party data-engineering analysis (2026-08). Observed version: v26.x, tier boundaries pending official verification

• One-line positioning: a distributed SQL built for "global multi-active + strong consistency"; using it for a small single-region database is overkill, and for cross-region core systems it's among the most complete choices in its class — provided you accept its licensing reality and the physics of latency.
• Who it's for:
  • OLTP core systems for multi-region/global businesses (users and data naturally partitioned, e.g. SaaS, cross-border, IoT platforms)
  • Finance/ledger systems with zero tolerance for incorrectness, willing to pay the Serializable latency tax
  • Teams with continuously growing data that want to never shard
  • Data-engineering teams needing native CDC into lakehouses (Kafka → Iceberg/Delta)
  • Small/medium teams under $10M revenue wanting free Enterprise capabilities (subject to contract wording)
• Who it's not for:
  • Workloads a standalone PG/MySQL can handle (you'd pay the latency, ops, and licensing taxes for nothing)
  • Teams heavily dependent on PG triggers/stored procedures/advisory locks/FDW/extension ecosystem that won't run a compatibility POC
  • Organizations needing source-level self-controllability (domestic substitution / strong regulation) or sensitive to the "going closed-source" trend
  • Budget-sensitive teams whose workload RU is hard to predict and who won't run a billing shadow test
  • Teams without dedicated DBA/ops wanting "install and forget" (certificates, NTP, upgrades, GC are all ongoing work)
• Migration cost:
  • MySQL → medium-high: no MySQL protocol — application-layer rework; transaction semantics differ greatly (Serializable vs REPEATABLE-READ); the auto-increment primary-key habit must change
  • PostgreSQL → low-medium: low protocol/driver-layer friction; but triggers, stored procedures, advisory locks, FDW, extensions, pg_stat_statements gaps need item-by-item POCs; default isolation-level differences need full regression
  • Oracle → high: no Oracle-compatibility path; not recommended as a "de-Oracle" target

• Versions and releases: third-party 2026 coverage (v26.3 GA ~2026-08-19; v26.2.4 self-hosted GA 2026-07-16); official compatibility docs already cover v26.3; official press releases (v25.4 as maintenance release 2026-02; Continuum 2026-01)
• License evolution: official blog (2024 licensing update; 2026 source-code-protection); SDTimes, The Register 2024 coverage
• Architecture: official design.md, range-merges tech note, follower reads / non-blocking txns RFCs, legacy storage-encryption RFC; cockroach start --enterprise-encryption docs (v24.2)
• Multi-region: Cockroach Labs official skills (survival goals / REGIONAL BY ROW); third-party 2026 analysis (latency measurements, PG comparison)
• Compatibility gaps: official postgresql-compatibility (v26.3); Authentik community spike (advisory locks); Storj historical migration case
• Operations: community ops handbook (rolling upgrade, certificates); Rancher helm chart (preserve_downgrade_option); official university skill (full-cluster restore requires enterprise license); official skills CIS audit sample (audit settings, OIDC, SCRAM)
• Cloud and billing: official docs cloud releases (Basic/Standard/Advanced; Serverless→Basic rename 2024-09-25); TechTarget 2024 (historical pricing); 2026 third-party deployment guide (Basic benefit, pending official verification)
• Complaint collection: HN historical discussion (2019, tombstone/latency); community performance retrospectives
• Next review must check: official v26.3 release notes (confirm patch number and GA date); v26.3 encryption/WAL coverage boundaries; tier matrix for audit/SSO/backup; Cloud 2026 current pricing; official statement on cluster.preserve_downgrade_option and version-skipping rules; READ COMMITTED default and semantics in v26.3