A PostgreSQL dedicated server for the database your app depends on

Will your data fit in memory?

That is the first question, because a query answered from RAM never waits on a disk. Think about the tables and indexes your app reads every day, not the total size on disk. If that hot part fits comfortably in memory, almost any modern storage will feel quick. If it does not, the drives start to matter a great deal.

PostgreSQL uses memory in two layers. Its own cache, called shared_buffers, ships at a cautious 128MB. The PostgreSQL manual suggests starting at 25% of the machine's memory when the server runs nothing but the database, and warns that going past 40% rarely helps, since PostgreSQL also leans on the operating system's file cache for everything else.

Then tell the planner about the rest with effective_cache_size. It reserves nothing; it only helps PostgreSQL judge whether an index lookup will probably be served from cache. Its default is 4GB, which undersells a large machine.

The setting that catches people out

work_mem looks small, 4MB by default, and it is tempting to raise it a lot. The catch is that it is not a total. Each sort or hash step inside a query may use that much, one query can have several such steps, and hash steps may use double (the hash_mem_multiplier default is 2.0). Multiply by the number of people connected at once and a generous value can push the box into swap.

A safer habit: keep the global value modest, and raise it only for the role that runs heavy reports. maintenance_work_mem, used by VACUUM and index builds, is different; only a few of those run at a time, so a gigabyte or more is fine on a big machine.

Keeping every commit safe

When your app saves an order, PostgreSQL writes it to its write-ahead log (WAL) and waits until the disk confirms it before saying success. That wait is why fast, honest storage matters, and why two well-known shortcuts deserve a clear answer.

1. Turning off fsync: do not, on anything you care about. The manual is blunt that a power cut or crash can then leave the database corrupted beyond repair. It is meant for throwaway data, like a first bulk load you could simply redo.
2. Turning off synchronous_commit: a reasonable trade for some data. A crash may lose the last fraction of a second of commits (at most three times wal_writer_delay, which defaults to 200ms), yet the database stays consistent, as if those transactions had been cancelled. You can switch it off for one session or transaction, say for click logs, while orders stay fully durable.

Before trusting a new box, run pg_test_fsync, which ships with PostgreSQL. It tells you how long a real flush takes on those disks, and the manual's reliability chapter shows how to check whether a drive's write cache is switched on, and warns that many SSDs keep volatile write caches that may not survive a power failure.

The server that fits

Our NVMe dedicated servers give PostgreSQL drives with very low latency, which is exactly where WAL waits. You get the whole physical machine, root access, and a port no other customer shares at the access switch, in any of our five cities, from Amsterdam and Bucharest to the three US sites.

• Protection against a dead drive: the blade and rack lines have hardware RAID, and the HPE Smart Array controllers on the blade lines carry a flash-backed write cache. The small m510, m710x and m750 cartridges mirror their drives in software instead.
• A part fails? It is replaced within four hours of your call.
• Growing later: memory and disks can be added to the server you already run, with no migration and no new IP address. The largest machines hold 2 TB of memory.
• A console when SSH will not answer: a remote management console (iLO, iDRAC or a BMC, depending on the maker) on every blade and rack server, and on the m510 and m710x cartridges too.

If you need a specific mix of memory and drives, build it part by part; a ready machine is online in about 30 minutes once approved, and a custom one usually in 4 to 24 hours. For databases that are mostly large and read-heavy, our storage servers are worth a look.

Up and running in an evening

1. Pick Ubuntu or Debian when you order. Both include PostgreSQL in their own package repositories.
2. Install it, then open psql as the postgres user.
3. Apply the memory settings for your machine size with ALTER SYSTEM and restart PostgreSQL once.
4. Create a role and database for your app with a password; PostgreSQL stores it as SCRAM-SHA-256 by default.
5. Decide who may connect (next section), then turn on WAL archiving before real data arrives.

apt install postgresql
sudo -u postgres psql

-- a 128 GB server running only PostgreSQL
ALTER SYSTEM SET shared_buffers = '32GB';
ALTER SYSTEM SET effective_cache_size = '96GB';
ALTER SYSTEM SET maintenance_work_mem = '2GB';
CREATE ROLE shop LOGIN PASSWORD 'choose-a-long-one';
CREATE DATABASE shop OWNER shop;

Who gets to connect

A fresh install only accepts connections from the machine itself, because listen_addresses defaults to localhost. If your app lives on another server, add that one address rather than opening every interface, and restart.

Next, pg_hba.conf decides which user, from which address, may reach which database, and how they prove it. PostgreSQL reads it from the top and uses the first line that fits; if that check fails it does not try the next line, and anything unmatched is refused. A tight rule names one database, one user and one address, ending in /32, with the scram-sha-256 method. Run SELECT pg_reload_conf(); to load the change, then check the pg_hba_file_rules view for mistakes. Avoid md5: the manual marks MD5 passwords as deprecated.

Recover to any minute, not just last night

A nightly pg_dump is a good start, but restoring it loses everything since. Point-in-time recovery closes that gap: take a full copy of the data directory with pg_basebackup, and keep every finished WAL file through archive_mode = on and an archive_command. To recover, restore the copy, point restore_command at the archive, set a target time just before the mistake and let PostgreSQL replay to it.

# a compressed base backup in tar format, with progress
pg_basebackup -D backup -Ft -z -P

We do not sell a backup product on these servers, so send the archive and base backups to storage off the machine, ideally in another city. And rehearse a restore once; a backup you have never restored is a hope, not a plan.

When a whole server is more than you need

A side project or one small app database does not need its own machine. Our Cloud VPS offers PostgreSQL as a free one-click app, with a database ready on first boot. Move up to dedicated hardware when the database is busy enough that sharing a host would slow it, or when you want the disks and memory to yourself; our free migration help covers the move.

Questions people ask

How big a server do I need for PostgreSQL?

Start from the data your app reads every day and pick memory that holds it with room to spare. Then choose disks for your write rate: NVMe for busy transactional work, larger arrays for big, mostly-read data. Cores matter less at first, since each connection is one process and many queries use a single core.

What should shared_buffers be?

On a server that runs only PostgreSQL, a quarter of RAM is the manual's suggested starting value, so 16GB on a 64 GB machine. Going past about 40% rarely helps. It needs a restart to change.

Can I lose data if the power fails?

Not committed data, as long as fsync and full_page_writes stay on and the disks or controller do not lose cached writes. If you set synchronous_commit to off, the most recent fraction of a second of commits may vanish in a crash, but nothing becomes corrupted.

Is it safe to open port 5432 to the internet?

It is better not to. Listen only on the address your application uses, let only that host in through pg_hba.conf using the scram-sha-256 method, and switch on SSL with hostssl lines whenever the traffic leaves a private link.

Does a dedicated server come with database backups?

No backup product is sold with our servers, so plan your own: pg_dump for simple copies, and pg_basebackup with WAL archiving for point-in-time recovery. Keep the copies on another machine.