How is this different from your general database use-case?

The general database page covers the whole picture — Postgres or Redis, sizing, when a shared box is the wrong tool. This one is PostgreSQL specifically: superuser, the full postgresql.conf, any extension you want, choosing your major version, and running pg_dump / WAL backups on your own schedule. If you specifically want self-hosted Postgres, this is the deep version; the general page is the overview.

Which extensions can I install?

Any of them — that's the point of self-hosting. pgvector for embeddings and semantic search, PostGIS for geospatial, TimescaleDB for time series, pg_cron, pg_stat_statements. Managed tiers often restrict the extension list or gate it behind a higher plan; with superuser on your own box you install whatever your workload needs.

How much RAM does PostgreSQL need?

For one app's database, 1.7–2 GB working set is realistic, so Small ($8/mo) fits. More apps, real production concurrency or a large pgvector index push you to Medium ($12) or higher. Tune shared_buffers and work_mem to the box; that tuning is a big reason to self-host in the first place.

How do other servers connect securely?

Bind Postgres to the right interface, open 5432 only to the specific IPs that need it (never 0.0.0.0/0), require TLS, and take a dedicated-IPv4 plan so the address is stable and routable. If the database only serves an app on the same box, keep it on localhost and expose nothing.

Do you ask for ID or a card?

No. Email to sign up, pay in USDC or USDT. Root in about a minute, then Postgres is a few commands away.

VPS for a PostgreSQL database (self-hosted, full control)

Self-host PostgreSQL on a VPS with superuser and the whole postgresql.conf — any extension (pgvector, PostGIS, TimescaleDB), your own version, your own backups. A managed-Postgres alternative you fully control. No KYC, pay in crypto. From $8/mo.

There's a moment where managed PostgreSQL stops being convenient: you want an extension the tier doesn't offer, you want to see the real query plan and tune work_mem, you want superuser. When you want to own Postgres — the config, the version, the extensions, the backup schedule — a VPS with full root is the honest answer. This is the PostgreSQL-specific setup; for the broader "self-host a database" picture (Postgres vs Redis, where a shared box is wrong), see the general database use-case.

Why self-host PostgreSQL

On your own box you get what managed tiers ration:

The whole postgresql.conf — shared_buffers, work_mem, max_connections, WAL settings, tuned to your workload, not a vendor default.
Any extension. pgvector for embeddings, PostGIS for geospatial, TimescaleDB for time series, pg_cron, pg_stat_statements — install what you need. This is where a managed tier most often says no.
Your major version, upgraded on your schedule, not the provider's.
Superuser and the OS underneath — move the data directory, tune the kernel, run streaming replication to a second box.

If pgvector is the reason you're here, note that Postgres-plus-pgvector is a complete vector store on one machine — the same building block behind a self-hosted RAG stack and agent memory.

Set it up (Ubuntu 24.04, Docker)

# docker-compose.yml — PostgreSQL 16 (+ pgvector via the pgvector image)
services:
  db:
    image: pgvector/pgvector:pg16
    restart: always
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: change-me-strong
      POSTGRES_DB: app
    command: ["postgres", "-c", "shared_buffers=512MB", "-c", "work_mem=32MB"]
    volumes: ["/srv/pg:/var/lib/postgresql/data"]
    ports: ["127.0.0.1:5432:5432"]   # localhost only; see below to expose safely

docker compose up -d
docker compose exec db psql -U app -c "CREATE EXTENSION IF NOT EXISTS vector;"

Bound to 127.0.0.1, it serves an app on the same box with nothing exposed. To let other servers in, that's the next section.

Letting other servers connect — safely

The moment another machine needs the database, two things change:

A stable, routable address — a dedicated-IPv4 plan (Small-IP $16, Medium-IP $20). NAT plans share an outbound IP, fine for outbound but not for being a database others dial into.
Firewall it hard. Open 5432 only to the specific client IPs, never 0.0.0.0/0, and require TLS. An open Postgres port on the public internet is found in minutes — lock it down with a UFW firewall.

Backups are your job

Self-hosting means backups are on you, and the rule is: do them before you need them. pg_dump on a cron for logical backups, or WAL archiving for point-in-time recovery on anything you care about. Ship the dumps off the box, and test a restore at least once — a backup you've never restored is a hope, not a backup. A managed-backups add-on is available if you'd rather not run it yourself.

Why EQVPS for PostgreSQL

Full root, superuser, your config — from $8/mo, NVMe (RAID1) that matters once a database and its WAL write at once.
No KYC, crypto payment. Email to register, USDC/USDT to pay.
EU (Germany, Finland), root in ~60 seconds. Bring your schema and go.

General database use-case (Postgres/Redis overview) → · Self-hosted RAG at scale →