For any plan

Whatever you host, check these first.

• Region and latency

  Run close to your users: every 1,000 km adds roughly 10 ms to each round trip. Keep the app and its database in the same region, or each query pays that too. Some data must stay in a country or region by law (GDPR, health or government data).

  On this page: Regions filter

• The whole bill, not the sticker price

  Egress, public IPv4 addresses, load balancers, extra disks, backups and NAT gateways are billed on top of the plan on the big clouds. They often cost more than the server itself for a small app.

  On this page: Extra costs column

• What “free” really means

  Free plans sleep when idle, expire after a trial period, pause after a week of no use, or are a monthly credit that runs out. Many still need a card, and some reclaim idle machines.

  On this page: Free-tier chips and the Budget and free tier filter

• A cap on the bill

  By default the big clouds only send budget alerts: they will not stop a runaway bill from a bug, a traffic spike or a leaked key unless you wire up an automatic shutdown yourself. Set alerts on day one, and prefer a platform with a hard spending limit for side projects.

• Commitment and lock-in

  1- and 3-year commitments cut the price a lot but are hard to undo. Proprietary services (DynamoDB, Firestore, Cosmos DB) are harder to leave than plain Postgres, containers or the S3 API.

  On this page: Contract length filter

• Backups and recovery

  Check what is backed up, how often, how long it is kept, and whether you can restore to a point in time. Test a restore once, and keep one copy with another provider.

• Room to grow

  Can you move to a bigger plan, add nodes or add a read replica without migrating? Budget hosts often top out early, and moving later costs a weekend and the egress to copy your data out.

• Managed or do it yourself

  A $5 VM is cheap until you count patching, monitoring, backups and being on call. A managed service costs more per GB and saves that time.

  On this page: Compare providers: the five kinds of provider

• Support, SLA and track record

  Free support is often forums only. An SLA gives credits, not your downtime back. A small host can be great value, but has less of a record to judge it on.

  On this page: Compare providers: reviews and complaints

• Security and compliance

  Look for two-factor sign-in, private networking, a firewall and DDoS protection. Customers in regulated fields may ask for SOC 2, ISO 27001, HIPAA or a GDPR data processing agreement.

Virtual machine

• Shared or dedicated CPU

  Shared and burstable vCPUs are cheap but can be throttled or slowed by noisy neighbours. Steady, CPU-heavy work wants dedicated cores.

  On this page: CPU column (shared, burstable, dedicated, Arm)

• x86 or Arm

  Arm machines give more per dollar, but check that your Docker images and any binaries ship an arm64 build.

• Enough RAM for everything on the box

  The OS, Docker, the app and a database on one VM add up: 1 GB is tight once a database runs beside the app.

  On this page: Size ranges: RAM

• Disk: included, type and size

  Some plans include a local NVMe disk, others bill network block storage separately (AWS EBS). Check the size, the speed and whether it survives the VM being stopped.

  On this page: Size ranges: Disk

• Traffic, IPv4 and port speed

  Developer clouds bundle terabytes of transfer; the big clouds charge per GB beyond a small free allowance (about 100 GB a month). A public IPv4 address may cost extra, and cheap hosts can cap the port speed.

  On this page: Network column

• You run the server

  Security updates, the firewall, SSH keys, monitoring and backups are yours. A panel such as Coolify or cPanel does some of it for you.

• Snapshots and backups cost extra

  Automatic backups are often an add-on of about 20% of the VM price. Without them, one bad upgrade can lose everything on the disk.

• Resizing

  Check you can resize up in place, and whether you can ever go back down: some hosts only grow the disk.

Container hosting

• CPU and RAM per instance, and how many

  A container over its memory limit is killed and restarted. Leave headroom, and count the instances you need for load and for zero-downtime deploys.

  On this page: How many and Size ranges

• Permanent storage

  A container's own filesystem is wiped on every deploy or restart. Uploads and data need a volume (Fly volumes, Render disks, Railway volumes), a database or object storage. Heroku and scale-to-zero platforms give you no permanent local disk at all.

  On this page: Add Object storage or a database as another service

• Region

  Where the containers run, and whether the database is in the same region. A platform with few regions may be far from your users.

  On this page: Regions filter

• Always on or scale to zero

  Scale-to-zero and free plans sleep when idle, so the next request waits for a cold start (up to a minute on some free tiers). Nothing runs in the background while it sleeps.

  On this page: Free-tier chips

• Request limits

  Check the request timeout (Heroku stops a request at 30 seconds), WebSocket support, and the largest upload allowed.

• Workers and scheduled jobs

  Queue workers and cron jobs usually run as separate services, billed like another container.

• Deploys

  From git, a Dockerfile or an image registry? Look for health checks, zero-downtime deploys, rollbacks and preview environments.

• Networking

  Private networking to the database, custom domains with free TLS, and a static outbound IP if a partner must allow-list you (often a paid add-on).

• Logs and metrics

  How long logs are kept, and whether you need to ship them elsewhere to search them.

PostgreSQL

• Storage and growth

  How much storage the price includes, what each extra GB costs, and whether it grows automatically or stops writes when full.

  On this page: Size ranges: Storage

• Connection limits

  Small plans allow only a few dozen connections. Serverless functions and many containers need a connection pooler (PgBouncer or the provider's own).

• Backups and point-in-time restore

  Daily backups lose up to a day of data. Point-in-time restore gets you back to a minute before a bad migration; check how many days it covers.

• High availability

  A single instance is down during maintenance and failures. A standby with automatic failover usually doubles the price.

• Version and extensions

  Check the Postgres version, how major upgrades are done, and that the extensions you need are allowed: pgvector, PostGIS, pg_cron, TimescaleDB.

• Sleep and cold starts

  Serverless Postgres (Neon) scales to zero and wakes on the next query. Some free projects pause after a week without activity.

  On this page: Free-tier chips

• Same region as the app

  Every query crosses the network. Use private networking, or at least TLS, and watch egress if the app is with another provider.

  On this page: Regions filter

• Getting your data out

  pg_dump works with every provider, which makes managed Postgres one of the easiest things to move.

MySQL

• Storage and growth

  How much storage the price includes, what each extra GB costs, and whether it grows automatically or stops writes when full.

  On this page: Size ranges: Storage

• MySQL or MySQL-compatible

  TiDB, Aurora and other MySQL-compatible databases speak the protocol but differ in features and limits. MariaDB has drifted from MySQL. Test your app against the real thing.

• Version

  MySQL 8.0 reached end of life in April 2026. Prefer a plan on 8.4 LTS, and check how upgrades are done.

• Connection limits

  Small plans allow few connections; many containers or serverless functions need pooling (ProxySQL or the provider's own).

• Backups and point-in-time restore

  Check how often backups run, how long they are kept, and whether binlog-based point-in-time restore is included.

• High availability

  A replica with automatic failover usually doubles the price, but keeps the site up through maintenance.

• Same region as the app

  Keep it next to the app, on a private network if the provider offers one.

  On this page: Regions filter

Redis / Valkey

• Memory

  The whole dataset lives in RAM, plus overhead. When it is full, the eviction policy decides whether old keys are dropped or writes fail.

  On this page: Size ranges: Memory

• Cache or data store

  A cache can lose everything on restart. Sessions, queues and rate limits cannot: check that persistence (RDB / AOF) is on, as some free tiers turn it off.

• Priced per request or by size

  Per-request pricing (Upstash) is cheap for a quiet app and expensive under heavy traffic. Fixed plans are the other way round.

• Latency

  A cache in another region adds the network trip it was meant to save. Keep it next to the app.

  On this page: Regions filter

• Redis or Valkey

  Valkey is the open-source fork made after Redis changed its licence in 2024. Ordinary commands work the same; JSON and search come as separate modules on each, so check that the one you need is offered.

• Connections and limits

  Small plans cap connections, request size and commands per second. Check them against your peak.

Object storage

• Egress

  Downloads are often the biggest part of an object storage bill: about $0.09/GB on the big clouds. Cloudflare R2 charges no egress, and Backblaze B2 is free up to 3× what you store.

  On this page: Extra costs column

• Request charges

  Uploads and reads are priced per 1,000 or per million. Millions of small files can cost more in requests than in storage.

• Storage classes

  Infrequent-access and archive classes are cheaper per GB but charge to read data back and bill a minimum number of days.

• S3 compatibility

  Most tools speak the S3 API. Check that the features you use (presigned URLs, multipart upload, lifecycle rules, versioning) are supported.

• Serving files to the public

  Put a CDN in front for speed and to cut egress, and use signed URLs for private files.

• Versioning and lifecycle rules

  Versioning keeps every old copy, and you pay for all of them. Add lifecycle rules to expire old versions and temporary files.

Kubernetes

• Control plane fee

  AWS EKS charges about $73/mo per cluster before any node. GKE's free credit covers one cluster, and AKS, DigitalOcean, Linode and Vultr have a free control plane (a highly available one costs extra).

  On this page: Price column

• Nodes are VMs

  You pay for the worker nodes like VMs, and need at least two or three to survive one failing.

  On this page: Size ranges: CPU and RAM per node

• Load balancers and ingress

  Each LoadBalancer service is usually a paid cloud load balancer. One ingress controller can share one.

• Persistent volumes

  Block storage is billed separately and tied to one zone, so a pod with a volume cannot move between zones.

• Upgrades and add-ons

  Each Kubernetes version is supported for about a year, so you upgrade regularly. Ingress, certificates, monitoring and autoscaling are yours to set up.

• Is it worth it

  For a handful of services, a PaaS or one VM with Docker Compose is far simpler. Kubernetes pays off with many services and a team to run it.

  On this page: Container hosting and Virtual machine services

NoSQL

• Data model and queries

  Key-value stores such as DynamoDB need your access patterns planned up front, and have no joins or ad-hoc queries. Document databases (MongoDB, Firestore) are more flexible.

• MongoDB API is not MongoDB

  DocumentDB, Cosmos DB and Oracle's JSON database speak the MongoDB protocol but miss some features and operators. Test your driver and queries.

  On this page: MongoDB API chip and the NoSQL engine filter

• How it is priced

  On-demand per request suits spiky traffic, provisioned capacity suits steady traffic, and a fixed cluster is the same price at any load. Estimate your reads and writes.

• Lock-in

  DynamoDB, Firestore and Cosmos DB exist only on their cloud. MongoDB runs anywhere, including your own server.

• Limits

  Item and document size caps differ: 400 KB in DynamoDB, 1 MiB in Firestore, 16 MB in MongoDB. Check them, and the limits on indexes and query results.

• Backups

  Point-in-time restore and continuous backup are often extra, and some free tiers have no backups at all.

Vector database

• Do you need a separate vector database

  Up to a few million vectors, Postgres with pgvector or MongoDB Atlas Vector Search keeps embeddings next to the rest of your data: one database, one bill, and filters and joins in the same query. A dedicated vector database (Pinecone, Qdrant) pays off at larger scale or for very low query latency.

  On this page: pgvector and Atlas plans are listed under Vector database

• Size it from vectors × dimensions

  Each float32 dimension is 4 bytes: 1 million 1,536-dimension embeddings (OpenAI text-embedding-3-small) is about 6 GB before the index and metadata, which can double it. Smaller or quantised embeddings cut that a lot.

  On this page: Size ranges: Storage

• How it is priced

  Serverless plans bill storage plus read and write units, so a busy search box costs more than the stored data. Cluster plans charge for the node whatever the load. Estimate queries a month, not just vectors stored.

• Filtering and hybrid search

  Most apps filter by user, tenant or date as well as by similarity, and many want keyword plus vector (hybrid) search. Check that metadata filters run inside the vector search, not after it, and whether sparse or full-text search is built in.

• Changing the embedding model

  Vectors from different models cannot be mixed, so a new model means re-embedding every document and rebuilding the index. Keep the source text so you can, and budget for the embedding calls.

• Free tiers pause

  Free vector plans are small, run in one cloud region, and are paused or deleted after a week or a few weeks without use. Fine for a prototype; not for a demo someone opens once a month.

  On this page: Free-tier conditions under each plan