Server cloud per PostgreSQL in Europa

Server cloud per PostgreSQL in Europa

Server cloud per PostgreSQL in Europa

PostgreSQL e il database scelto per le applicazioni che necessitano di affidabilità, query complesse e rigida integrità dei dati. Se i tuoi utenti o la tua azienda si trovano in Europa, eseguire PostgreSQL su un server cloud EU non e solo una preferenza tecnica - e una necessita legale ai sensi del GDPR.

Perché la residenza dei dati in UE e importante per PostgreSQL

Il GDPR richiede che i dati personali dei residenti UE vengano elaborati sotto la giurisdizione europea. Ospitare il tuo database PostgreSQL su un server fisicamente situato nell'UE e gestito da un'azienda europea soddisfa i requisiti di residenza dei dati senza accordi complessi con gli hyperscaler americani.

Inoltre, i server EU offrono una latenza inferiore per gli utenti europei. Un database a Francoforte o Praga risponde a un'applicazione berlinese 30-80 ms più velocemente rispetto a uno ospitato in Virginia.

Specifiche minime per PostgreSQL

  • Piccolo (dev/staging) - 4 vCPU, 8 GB RAM, 100 GB NVMe SSD
  • Medio (app di produzione) - 8 vCPU, 32 GB RAM, 500 GB NVMe SSD
  • Grande (analytics o OLTP ad alta scrittura) - 16+ vCPU, 64-128 GB RAM, 1+ TB NVMe SSD

Configurazione DCXV raccomandata

I server cloud DCXV funzionano su infrastruttura certificata Tier III nell'UE con storage NVMe. Una configurazione di produzione PostgreSQL pratica su DCXV:

  • 8 vCPU, 32 GB RAM, 500 GB NVMe - gestisce la maggior parte dei database SaaS di produzione
  • 16 vCPU, 64 GB RAM, 1 TB NVMe - database analitici con query di reporting concorrenti

Contatta sales@dcxv.com per una raccomandazione di configurazione.

Comandi di configurazione rapida

# Installare PostgreSQL 16 su Ubuntu 22.04
sudo apt update && sudo apt install -y postgresql-16

# Avviare e abilitare il servizio
sudo systemctl start postgresql
sudo systemctl enable postgresql

# Creare database e utente
sudo -u postgres psql -c "CREATE DATABASE myapp;"
sudo -u postgres psql -c "CREATE USER myapp_user WITH ENCRYPTED PASSWORD 'strongpassword';"
sudo -u postgres psql -c "GRANT ALL PRIVILEGES ON DATABASE myapp TO myapp_user;"
# Impostazioni chiave postgresql.conf per 32 GB RAM
shared_buffers = 8GB
effective_cache_size = 24GB
work_mem = 64MB
maintenance_work_mem = 2GB
max_connections = 200

Cosa fa davvero ogni impostazione di memoria

I quattro valori di quel blocco di configurazione non sono arbitrari, e solo uno di essi è un limite per server. Confondere questa differenza è il motivo per cui una macchina con RAM in abbondanza finisce per usare lo swap:

Impostazione Che cosa copre Valore sopra Come si scopre che è sbagliata
shared_buffers La cache delle pagine condivisa, una per server 8 GB Le letture continuano ad andare su disco mentre la memoria libera resta inutilizzata
work_mem Un ordinamento o un hash, per operazione 64 MB Nel log compaiono file temporanei, o il server va in swap sotto carico
maintenance_work_mem VACUUM e costruzione degli indici, per worker 2 GB Autovacuum non termina mai sulla tabella più grande
effective_cache_size Niente - è un suggerimento per il planner 24 GB Il planner sceglie una scansione sequenziale invece di un indice perfettamente buono

work_mem è quello che fa male. Si applica per ordinamento, non per connessione, quindi una query con tre ordinamenti su cinquanta connessioni può chiedere centocinquanta volte il valore impostato. Alzalo per la singola query di reporting che ne ha bisogno, dentro quella sessione, e non per tutto il server.

Prestazioni attese

Su un'istanza da 8 vCPU / 32 GB RAM / NVMe con PostgreSQL 16:

  • pgbench TPS (solo lettura) - 12.000-18.000 TPS
  • pgbench TPS (lettura-scrittura) - 4.000-7.000 TPS
  • Latenza di ricerca riga singola (con indice) - meno di 0,5 ms

Queste sono aspettative per hardware di questa classe, non misurazioni dal nostro laboratorio. Prendile come punto di partenza per il dimensionamento e misura il tuo carico: i numeri reali dipendono dai tuoi dati, dalle tue query e dal tuo tuning molto più che dal fornitore.

PostgreSQL raramente gira da solo. Per pianificare la memoria del database accanto ad API, worker e cache, vedi Server cloud per SaaS: dimensionare CPU, RAM, NVMe e backup, un esempio svolto con Docker Compose.

Conclusione

PostgreSQL su un server cloud EU offre conformità GDPR, bassa latenza per gli utenti europei e pieno controllo sui tuoi dati. Inizia con un'istanza DCXV correttamente dimensionata e applica i parametri di tuning sopra indicati.

Starlink Mini 2 dietro CGNAT: raggiungere un sito che si sposta
networkingcloudinfrastructure

Starlink Mini 2 dietro CGNAT: raggiungere un sito che si sposta

Arriva la Starlink Mini 2, ma i piani standard stanno dietro CGNAT. Abbiamo contato 990.208 IPv4 per oltre 12 mln di clienti: ecco quattro modalità d'accesso.

Proteste contro i data center in Europa: cosa fare ora
clouddedicatedinfrastructure

Proteste contro i data center in Europa: cosa fare ora

Il 6 novembre centinaia di persone sono entrate nel cantiere Microsoft di Amsterdam. Rete olandese, latenza misurata e cosa fare ora per la continuità.

Voto USA, data center bocciati 45 a 1: lezioni per i clienti
clouddedicatedinfrastructure

Voto USA, data center bocciati 45 a 1: lezioni per i clienti

47 quesiti locali sui data center negli USA, il fronte restrittivo ne ha vinti 45. Ricontiamo i dati grezzi e spieghiamo cosa comporterà per chi affitta server.

AWS BYOIP nel 2026: $43.80 per IPv4 o un tuo blocco /24
ipv4pricingcloud

AWS BYOIP nel 2026: $43.80 per IPv4 o un tuo blocco /24

AWS addebita $0.005 l'ora per IPv4 pubblico, $43.80 all'anno. Il BYOIP è esente: quando un /24 comprato o in affitto si ripaga, con un controllo della ROA.

Lasciare VMware dopo Broadcom: guida alla migrazione
clouddedicatedinfrastructure

Lasciare VMware dopo Broadcom: guida alla migrazione

Broadcom ha chiuso le licenze perpetue, tagliato i partner e nascosto VDDK. Come spostare VM su KVM, Proxmox o Hyper-V: date e una conversione OVA già testata.