EQVPS

VPS for self-hosted RAG at scale

Retrieval-augmented generation stops being a laptop demo once the corpus is real. A vector index wants RAM, and your embeddings are your private data. Here's the sizing math and why high-memory, no-KYC hosting fits. From $55/mo.

A RAG demo on a laptop with two hundred documents feels effortless. Then you point it at a real corpus — a company's docs, years of tickets, an actual knowledge base — and the whole thing becomes a memory problem. Not a CPU problem. A memory one.

Here's the part most hosting pages skip: fast retrieval wants the index in RAM. Every chunk of text becomes an embedding — a vector a few hundred to a couple thousand numbers wide — and searching means comparing your query against all of them, quickly. On disk it works, but every query pays a latency tax, and low-latency retrieval was the reason you self-hosted in the first place.

The sizing math, honestly

Measure your own corpus — dimension and index type swing this a lot — but as a starting feel:

We wrote out the full RAM curve here if you want the details.

Why high-memory and no-KYC together

Renting 48 GB of RAM is easy. Renting it with crypto and no identity check is not — most hosts that sell serious memory cheaply do it behind a card and a KYC form. Your embeddings aren't abstract numbers; they encode the text they came from. Your docs, your customers' content, turned into vectors. If that data is sensitive enough that you're paying privately, a managed vector cloud undoes the whole point — and so does a host that ties the server to your identity.

That combination — high memory, dedicated IP, crypto, no KYC, nightly backups — is what the Pro line is for. It's not the cheapest per gigabyte, and if you don't need privacy you can find RAM cheaper elsewhere. But if the index is your product and it can't leave, this is the shape that fits.

Where to start

Pick a plan with headroom for the index plus everything around it — the app, the model client, room to grow. For most real corpora that's Pro-48 (48 GB); a large one goes to Pro-64 or Pro-80. Load a sample first, watch memory, size from the number you measured — not the one you feared.

If your retrieval is part of a bigger agent system, the same box often holds the agent fleet too — that's how a 48 GB plan quietly becomes a 64 GB one.

Ready to deploy? Pay with crypto, no KYC — live in about a minute.

Deploy now →

FAQ

How much RAM does my RAG setup actually need?

It scales with embedding count and vector width. A few hundred thousand chunks fit in 2–4 GB; low millions, with the app and OS around them, land at 16–32 GB; tens of millions push 48 GB and beyond. Measure a sample, watch resident memory, extrapolate — don't guess high, you'll just overpay.

Why not use a managed vector service?

Two reasons people actually self-host: your embeddings encode private data (docs, notes, customer content), so keeping them on a machine you control matters; and cost is flat — a managed service meters by vectors and queries, a VPS is one monthly number you can hammer as hard as you like.

pgvector or a dedicated engine?

If you already run Postgres, pgvector is the least-effort path — one extension. For millions of vectors with heavy filtering, a purpose-built engine like Qdrant earns its own service. Start with what you operate; split it out when search slows, not before.

Do I need a GPU for RAG?

No. Retrieval is CPU + RAM work — comparing vectors, not generating text. The generation step calls your LLM (an API, or a separate model host). A high-memory CPU box is exactly the right shape for the retrieval half.

Comments

No comments yet. Be the first.

Leave a comment

Comments are moderated before they appear.