Cloud Server for PostgreSQL in Europe: GDPR Setup Guide
PostgreSQL is the database of choice for applications that need reliability, complex queries, and strict data integrity. If your users or business are based in Europe, running PostgreSQL on an EU cloud server is not just a technical preference - it is a legal and commercial necessity under GDPR.
This guide covers what hardware PostgreSQL needs, how to provision a compliant EU cloud server, and how to get your instance running in under an hour.
Why EU Data Residency Matters for PostgreSQL
GDPR requires that personal data about EU residents be processed under EU jurisdiction. Hosting your PostgreSQL database on a server physically located in the EU - operated by an EU-based company - satisfies data residency requirements without complex data processing agreements with US hyperscalers.
Beyond compliance, EU servers deliver lower latency to European users. A database in Frankfurt or Prague responds 30-80ms faster to a Berlin application than one hosted in Virginia. For transactional workloads, that difference compounds into real user experience improvements.
Minimum Specs for PostgreSQL
The right spec depends on your workload, but these are practical starting points:
- Small (dev/staging, under 10k rows/s) - 4 vCPU, 8 GB RAM, 100 GB NVMe SSD
- Medium (production app, 10k-100k rows/s) - 8 vCPU, 32 GB RAM, 500 GB NVMe SSD
- Large (analytics or high-write OLTP) - 16+ vCPU, 64-128 GB RAM, 1+ TB NVMe SSD
PostgreSQL benefits heavily from RAM - the larger your shared_buffers and effective_cache_size, the less disk I/O you generate. NVMe storage is important for write-heavy workloads because WAL writes are sequential but frequent.
Recommended DCXV Configuration
DCXV cloud servers run on Tier III certified infrastructure in the EU with NVMe-backed storage and dedicated network uplinks. A practical PostgreSQL production setup on DCXV:
- 8 vCPU, 32 GB RAM, 500 GB NVMe - handles most production SaaS databases
- 16 vCPU, 64 GB RAM, 1 TB NVMe - analytics databases with concurrent reporting queries
- Full EU data residency with ISO 27001 certified data centers
- Private networking between app and database servers at no extra cost
Contact sales@dcxv.com to discuss your specific workload and get a configuration recommendation.
Quick Setup Commands
# Install PostgreSQL 16 on Ubuntu 22.04
sudo apt update && sudo apt install -y postgresql-16
# Start and enable the service
sudo systemctl start postgresql
sudo systemctl enable postgresql
# Switch to postgres user and open psql
sudo -u postgres psql
# Create a database and user
CREATE DATABASE myapp;
CREATE USER myapp_user WITH ENCRYPTED PASSWORD 'strongpassword';
GRANT ALL PRIVILEGES ON DATABASE myapp TO myapp_user;
\q
# Key postgresql.conf tuning for a 32 GB RAM server
# Edit /etc/postgresql/16/main/postgresql.conf
# Memory settings
shared_buffers = 8GB # 25% of RAM
effective_cache_size = 24GB # 75% of RAM
work_mem = 64MB # per sort/hash operation
maintenance_work_mem = 2GB # for VACUUM, CREATE INDEX
# Write performance
wal_buffers = 64MB
checkpoint_completion_target = 0.9
max_wal_size = 4GB
# Connections
max_connections = 200
# Restart after changes
sudo systemctl restart postgresql
# Allow remote connections (edit pg_hba.conf)
# Add your app server's private IP
echo "host myapp myapp_user 10.0.0.0/24 scram-sha-256" | sudo tee -a /etc/postgresql/16/main/pg_hba.conf
# Also update postgresql.conf to listen on private IP
sudo sed -i "s/#listen_addresses = 'localhost'/listen_addresses = '10.0.0.5,localhost'/" /etc/postgresql/16/main/postgresql.conf
sudo systemctl reload postgresql
What each memory setting actually does
The four values in that config block are not arbitrary, and only one of them is a limit per server. Getting that difference wrong is how a machine with plenty of RAM ends up swapping:
| Setting | What it covers | Value above | How you learn it is wrong |
|---|---|---|---|
| shared_buffers | The shared page cache, once per server | 8 GB | Reads keep hitting disk while free memory sits unused |
| work_mem | One sort or hash, per operation | 64 MB | Temporary files appear in the log, or the server swaps under load |
| maintenance_work_mem | VACUUM and index builds, per worker | 2 GB | Autovacuum never finishes on the largest table |
| effective_cache_size | Nothing - it is a hint to the planner | 24 GB | The planner picks a sequential scan over a perfectly good index |
work_mem is the one that bites. It applies per sort, not per connection, so a query with three sorts running on fifty connections can ask for a hundred and fifty times the number you set. Raise it for the one reporting query that needs it, inside that session, rather than for the whole server.
Expected Performance Benchmarks
On an 8 vCPU / 32 GB RAM / NVMe instance with PostgreSQL 16 and proper tuning:
- pgbench TPS (read-only, scale 100) - 12,000-18,000 TPS
- pgbench TPS (read-write, scale 100) - 4,000-7,000 TPS
- Single-row lookup latency (indexed) - under 0.5ms
- Bulk INSERT (1M rows) - under 60 seconds
These numbers assume the working set fits in shared_buffers. For datasets larger than RAM, SSD throughput becomes the bottleneck - NVMe storage on sustains 3,000+ MB/s sequential read, which keeps latency acceptable even when cache misses occur.
These are expectations for hardware of this class, not measurements from our own lab. Treat them as a starting point for sizing and measure your own workload: real numbers depend on your data, your queries and your tuning far more than on the provider.
Bottom Line
PostgreSQL running on an EU cloud server gives you GDPR compliance, low latency for European users, and full control over your data. Start with a properly sized DCXV instance, apply the tuning parameters above, and you will have a production-ready database in well under an hour.
