I'm considering moving an existing production backend from managed Supabase to a self-hosted Supabase deployment on AWS. The Next.js frontend will stay on Netlify and behind a CDN, so the EC2 instance would handle PostgreSQL 17, authentication and Google OAuth, PostgREST/RPCs, Storage API, edge and background functions, scheduled jobs, remote job ingestion, AI summary processing, job alerts, and apply-link validation.
The workload is mostly read-heavy, with public traffic heavily cached. Ingestion is deliberately limited to one source at a time with concurrency set to 1. My initial plan is a Graviton t4g.large with 2 vCPUs and 8 GB RAM, using 60–80 GB gp3 EBS for PostgreSQL and S3 for uploaded or static objects.
I'm trying to avoid paying for unnecessary capacity while the product is still early-stage. The alternatives are a t4g.xlarge with 4 vCPUs and 16 GB RAM, or an M-series Graviton instance if sustained database and worker activity makes a burstable T-series instance unsuitable.
Would you begin with t4g.large and resize based on monitoring, or is 2 vCPUs and 8 GB too tight for PostgreSQL, APIs, and background workers on the same production host? I'm especially interested in CPU-credit behavior, memory usage, ARM64 compatibility with Docker workloads, gp3 settings, whether m7g is worthwhile, useful resize thresholds, and whether workers should be separated from the database immediately. Reliability, backups, failover, and the operational tradeoffs of replacing managed database infrastructure are also important considerations.
3 Answers
The instance size is only part of the decision. The workload descriptions are too broad to predict capacity reliably: AI processing, scheduled jobs, ingestion, and database queries could be trivial or could consume most of the machine. Measure representative peak traffic and run a load test before committing.
A t4g.large can be a reasonable starting point if downtime and occasional throttling are acceptable, but monitor CPU credits, CPU utilization, load average, memory pressure, swap activity, PostgreSQL connections, query latency, worker queue depth, and disk I/O. Set clear thresholds for resizing rather than relying on averages; sustained CPU above roughly 60–70%, declining CPU credits, memory pressure, or rising database latency would be warning signs.
I’d be more concerned about the single-server production design than choosing between 2 and 4 vCPUs. EBS is durable, but one EC2 host still leaves you exposed to instance, availability-zone, deployment, filesystem, and operator failures. At minimum, use automated encrypted snapshots and tested restores, and keep regular PostgreSQL backups in S3 with a tool such as pgBackRest or an equivalent approach. If the data is important, plan for a standby or managed PostgreSQL service in another AZ and define your recovery-point and recovery-time goals.
For gp3, begin with the default baseline and increase provisioned IOPS or throughput only when monitoring shows storage saturation. Database performance will also depend heavily on indexes, query plans, connection pooling, autovacuum, and avoiding oversized concurrent workers. Self-hosting can reduce the bill, but make sure the savings justify taking on backups, upgrades, failover, security patching, and database operations yourself.
For a database that may run continuously, I’d generally favor an M-series instance over a T-series once the workload is known to be steady. Burstable instances are useful when the baseline is low and activity comes in short bursts, but sustained CPU usage can exhaust credits and make performance less predictable. An m7g or similar Graviton instance gives you consistent CPU, and ARM64 is usually fine as long as every container image and native dependency supports it.
Keeping the database, API, and workers together may be fine at this stage if the jobs are bounded and resource limits are enforced. The first component I’d separate is CPU- or memory-heavy AI processing, since it can interfere with database latency. Start with t4g.large only if you have a tested recovery and resize path; otherwise 4 vCPUs and 16 GB provides considerably more headroom for a modest cost increase.
The important distinction is not just average CPU usage. A steady workload that consumes credits all day behaves very differently from occasional bursts, so watch the credit balance over several days including peak periods.