CockroachDB Review 2025: Database Distribuito per Cloud

Nel 2024, un'azienda fintech europea ha perso 2.3 milioni di euro in 4 ore perché il loro database centralizzato ha subito un single point of failure durante un picco di traffico. Dopo la migrazione a un database distribuito, lo stesso evento ha causato zero downtime. Questo è il contesto in cui ogni architetto cloud deve oggi valutare soluzioni come CockroachDB.

Secondo Gartner, entro il 2027 più del 50% delle applicazioni mission-critical utilizzerà database distribuiti nativi per il cloud. Per chi gestisce infrastrutture AWS, Azure o GCP con requisiti di disponibilità 99.99%+, questa non è più un'opzione: è una necessità strategica.

Il Problema Centrale: Perché i Database Tradizionali Non Bastano Più

I database relazionali centralizzati rappresentano ancora lo standard per il 78% delle applicazioni enterprise (Flexera State of the Cloud 2024). Tuttavia, l'architettura monolitica tradizionale collide con tre realtà operative moderne.

Latenza geografica killers.** Un'istanza PostgreSQL a Francoforte risponde in 180ms a un utente a Singapore. Per applicazioni real-time, questo gap è inaccettabile. CockroachDB risolve questo problema replicando i dati in multiple regioni e instradando le query verso il nodo più vicino automaticamente.

Scale-out impossibile. PostgreSQL classico scala verticalmente fino a un limite fisico. Quando il carico supera le 50.000 TPS su una singola istanza, le opzioni sono costose: RDS Multi-AZ ha un costo orario che cresce linearmente, mentre CockroachDB distribuisce il carico su nodi commodity.

Disaster recovery come costo, non come feature. Con PostgreSQL tradizionale, un RPO (Recovery Point Objective) sotto i 5 minuti richiede replica log shipping, backup incrementali, e team dedicati. CockroachDB integra nativamente la geo-replication con RPO teorico zero.

Un caso concreto: un cliente nel settore healthcare con 12 milioni di record paziente deve garantire conformità GDPR con dati residenti in EU. La soluzione PostgreSQL richiedeva 3 instance separate (primary + 2 replica) per copertura geografica e complessa gestione di failover. Dopo migrazione a CockroachDB su AWS e OCI, il team ha ridotto i costi infrastrutturali del 40% mantenendo latency sotto 15ms per il 95% delle query.

Analisi Tecnica Approfondita di CockroachDB

Architettura Distribuita e Modello di Consistenza

CockroachDB implementa un'architettura shared-nothing dove ogni nodo gestisce una porzione disjuntta (range) dei dati. Il protocollo di consenso Raft garantisce che ogni write sia replicato su almeno 3 nodi prima del commit.

Il modello di consistenza è serializable per default, ma supporta anche snapshot isolation per workload analytics. Questa flessibilità è cruciale: transazioni finanziarie richiedono serializzabilità, mentre analytics su dati storici possono tollerare consistenza eventuale per performance superiori.

-- Configurazione per massimizzare locality delle query
CREATE TABLE orders (
    id UUID PRIMARY KEY,
    customer_id UUID,
    region STRING,
    total DECIMAL
) PARTITION BY LIST (region) (
    PARTITION eu VALUES IN ('it', 'fr', 'de', 'es'),
    PARTITION us VALUES IN ('us-east', 'us-west'),
    PARTITION apac VALUES IN ('sg', 'jp', 'au')
);

-- Query che automaticamente instrada verso regione più vicina
SET session locality = 'region=eu';
SELECT * FROM orders WHERE region = 'it';

Comparazione: CockroachDB vs PostgreSQL vs Spanner

La tabella rivela una verità scomoda: PostgreSQL è ancora la scelta più economica per workload monoregione. Ma quando servono multi-region e auto-scaling, CockroachDB batte Spanner in flessibilità di deployment.

CockroachDB Cloud Hosting: Opzioni e Trade-off

CockroachDB Dedicated (fully managed):

• Pro: Zero ops, SLA garantito, geo-partitioning automatico
• Contro: Costo elevato ($225/vCPU/mese), lock-in vendor
• Ideale per: Startup con team piccoli, compliance strict

CockroachDB Serverless (preview):

• Pro: Pay-per-request, scaling automatico a zero
• Contro: Latency variabile, limiti di throughput
• Ideale per: Sviluppo, ambienti di test, workload sporadici

Self-hosted su Kubernetes:

• Pro: Controllo totale, costo ottimizzabile su cloud commodity
• Contro: Operational overhead, richiede competenze distribuite
• Ideale per: Enterprise con team platform成熟, requisiti specifici di data residency

# Terraform: deployment CockroachDB su AWS EKS
resource "aws_eks_cluster" "cockroach" {
  name = "cockroach-prod"
  version = "1.28"
  role_arn = aws_iam_role.eks.arn

  vpc_config {
    subnet_ids = [aws_subnet.private["a"].id, aws_subnet.private["b"].id]
  }
}

resource "helm_release" "cockroachdb" {
  name = "cockroachdb"
  repository = "https://charts.cockroachdb.com/"
  chart = "cockroachdb"
  version = "1.0.0"

  set {
    name  = "statefulset.replicas"
    value = "3"
  }
  set {
    name  = "storage.persistentVolume.size"
    value = "100Gi"
  }
  set {
    name  = "storage.persistentVolume.storageClass"
    value = "gp3"
  }
}

Implementazione Pratica: Migrazione PostgreSQL to CockroachDB

Step-by-Step Migration Framework

Fase 1 — Assessment (Settimana 1-2)

Prima di toccare codice, analizza la compatibilità del tuo schema:

-- Query per identificare feature PostgreSQL non supportate
SELECT 
    proname AS function_name,
    proargtypes::regtype[] AS arguments
FROM pg_proc
WHERE pronamespace = 'public'::regnamespace
  AND proname NOT IN (
    SELECT func_name FROM cockroachdb_compatibility_matrix
  );

CockroachDB non supporta: stored procedures con transazioni parziali, trigger BEFORE per aggiornamenti massivi, full-text search nativo (richiede external indexer).

Fase 2 — Schema Translation

Usa pg_dump con flag di compatibilità, poi refactora manualmente:

# Export schema PostgreSQL
pg_dump -h postgres-prod \
  -U admin \
  -d myapp \
  --schema-only \
  --no-owner \
  --no-acl \
  > schema.sql

# Refactoring necessario post-export:
# 1. SERIAL → IDENTITY
# 2. UUID v1 (time-based) → UUID v4 (random) 
# 3. ARRAY types → JSONB columns
# 4. Partial indexes → expression indexes

Fase 3 — Data Migration (Zero-downtime)

Per database con più di 10GB, usa Changefeeds per migrazione incrementale:

-- Setup changefeed su CockroachDB per replicare da PostgreSQL
CREATE CHANGEFEED FOR orders, customers, products
  WITH format = 'json', envelope = 'key_only'
  INTO 'experimental://your-cdc-connector';

-- Oppure usa pg_dump fisico per migrazione one-time:
docker run -v /data:/data \
  cockroachdb/cockroach:v23.2 import pgdump \
  --url='postgresql://user:pass@pg-host:5432/db' \
  /data/dump.sql

Fase 4 — Performance Tuning

Dopo migrazione, esegui EXPLAIN ANALYZE per ogni query critica:

-- Verifica distribution dei range (evita hot spots)
SELECT 
    region,
    range_id,
    lease_holder_locality,
    replicas_by_locality
FROM crdb_internal.ranges
WHERE table_name = 'orders'
ORDER BY range_id;

-- Tuning: ridistribuzione manuale se needed
ALTER TABLE orders
  SET locality = GLOBAL;

Integrazione con Ecosystem Cloud

AWS: CockroachDB si integra con IAM per authentication, CloudWatch per metriche, e S3 per backup:

# Backup verso S3 con encryption automatica
BACKUP INTO 's3://my-bucket/cockroach-backups/'
  WITH detached, encryption_passphrase = '...',
  revision_history;

# Restore cross-region
RESTORE TABLE orders 
  FROM 's3://my-bucket/cockroach-backups/' 
  AS OF SYSTEM TIME '-10s';

GCP: BigQuery Integration via External Queries per analytics ibride:

-- Query BigQuery da CockroachDB
SELECT *
FROM external (
  'bq', 'project.dataset.table',
  key_value_pairs(
    'project_id', 'my-gcp-project',
    'credentials_json', '{...}'
  )
) AS bq_data;

Errori Comuni da Evitare

1. Ignorare lo statement_timeout.
CockroachDB non ha query planner advanced come PostgreSQL. Query che in Postgres terminano in 50ms possono esplodere a 30 secondi se manca SET statement_timeout = '5s'. Causa: scan distribuiti senza filter su tabelle con milioni di righe.

2. Dimensionare nodi con storage sottodimensionato. Ogni nodo richiede spazio per: dati attivi (50%), write intent log (20%),预留 (15%), overhead Raft (15%). Formula corretta: storage_per_node = (dati_totali / 3) × 1.8.

3. Non configurare zone constraints. Senza ALTER DATABASE ... PLACEMENT_restriction = 'region=eu', i dati sono distribuiti random. Per GDPR compliance, questo è un fail catastofico.

4. Usare UUID v1 come primary key. UUID v1 è time-ordered e causa sequential writes sullo stesso range. Risultato: hot spot su un singolo nodo con degrado drammatico in write-heavy workload. Soluzione: gen_random_uuid() o ULID.

5. Underestimare il costo di full-table scan. In PostgreSQL, SELECT COUNT(*) è O(1) con statistics aggiornate. In CockroachDB, è O(n) su tutti i range. Per dashboard real-time, pre-aggrega in materialized views.

Raccomandazioni e Next Steps

Scegli CockroachDB quando:

• Hai requisiti multi-region con latency < 50ms globale
• Il tuo team è piccolo (< 5 DBA) e non può gestire failover manuale
• Operi in settori regolamentati dove data residency è mandatory
• Il tuo workload ha pattern write-hotspot che Postgres non gestisce con sharding manuale

Resta su PostgreSQL quando:

• Il workload è 100% monoregione
• Budget è la primary constraint
• Servono feature advanced: PostGIS, full-text search, stored procedures complesse
• Il team ha competenze PostgreSQL profonde e budget limitato per migration

Per chi vuole procedere: inizia con CockroachDB Serverless per un progetto pilota. Il tier gratuito (10GB storage, 10M request/mes) è sufficiente per validare performance e compatibilità applicativa. Dopo 30 giorni, analizza i costi reali prima di committare su Dedicated.

L'adozione di database distribuiti non è più questione di "se" ma di "quando". La differenza tra chi migra proattivamente e chi aspetta il prossimo outage da 2 milioni di euro la farà la qualità della valutazione di oggi.