Does AWS Amplify cost more than self-hosted Supabase for your app?
The answer depends on your usage shape, your team's operating skills and how much downtime you can tolerate, not on a single headline price. A renewal, a usage spike or a bill spread across Cognito, AppSync, DynamoDB, Lambda and S3 is usually the trigger, but the comparison only becomes useful once you separate what Amplify meters from what self-hosting costs you. Amplify charges are metered per component: Hosting build minutes, storage, data served and server-side rendering are billed by Amplify, while Cognito, AppSync, DynamoDB, Lambda and S3 are billed separately under their own AWS pricing. Self-hosted Supabase costs are servers plus the people who run them. The Supabase license, Apache-2.0, carries no license fee, so the money you pay is for infrastructure and operating time.
Start by sizing the server side. The self-hosting docs list minimum requirements of 4 GB RAM, 2 CPU cores and a 40 GB SSD, with 8 GB RAM, 4 cores and 80 GB recommended. Those figures are a starting point for a single project, not a capacity plan, because the Docker Compose stack runs Studio, Auth, PostgREST, Realtime, Storage, Edge Runtime and the connection pooler alongside Postgres. Ask your cloud or hosting provider for quotes on the recommended tier, plus backup storage and egress. Then estimate operating time: patching Docker images, applying upgrades that may require a database backup first, monitoring, and on-call coverage. Self-hosted Supabase is community-supported, so that time falls on your team or your implementation partner.
Run a two-column model with your current Amplify bill broken down by service for the last three months, and mark which costs disappear, which move to your servers and which stay (for example, any S3 usage that you keep). Then decide what availability you need. Hosted features such as managed backups and point-in-time recovery are not available when you self-host Supabase, so the cost of building your own backup and restore process belongs in the model. Confirm each figure with the vendor or with your own environment before you compare totals.
Which cost components move when you self-host Supabase
This table sets each metered or separately billed Amplify component against the self-hosted cost line that replaces it, and marks whether each item is one-time or recurring. Read the recurring rows first, since they decide the long-term comparison, then check the one-time migration and setup rows. Your actual figures depend on your AWS bill and your own server and staffing costs, so confirm them against your invoices and a written scope.
| Cost component | Amplify side (AWS billed) | Self-hosted Supabase side (you pay) | One-time or recurring |
|---|---|---|---|
| Hosting builds and SSR | Metered: build minutes, data served and SSR compute billed by Amplify Hosting usage | Fixed: servers or VMs that run the Docker Compose stack, sized to peak load and not to build minutes | Recurring |
| Storage and file delivery | Metered: S3 storage and requests, plus Amplify hosting storage and transfer | Fixed: disk on the Supabase Storage host and bandwidth from your own network, plus any object store you add | Recurring |
| Authentication | Metered: Cognito monthly active users, with user pools billed separately from the rest of the backend | Fixed: Supabase Auth runs on the same servers, so cost is the host capacity; user hash migration is a one-time effort | Recurring (hosting), one-time (user migration) |
| Database and API layer | Metered: DynamoDB read and write capacity and storage, plus AppSync request and data charges | Fixed: one Postgres instance, PostgREST and Realtime on your servers, sized by memory and disk | Recurring |
| Functions | Metered: Lambda invocations, duration and memory | Fixed: Edge Runtime on Deno runs on the same hosts; functions must be rewritten from Lambda and AppSync resolvers | Recurring (hosting), one-time (rewrite) |
| Backups and recovery | Included in the managed service design; confirm the retention and restore terms for each AWS service in your account | Self-hosted cost: Supabase's self-hosting docs list managed backups and PITR as unavailable, so you buy and run backup tooling and test restores | Recurring |
| Monitoring and logs | Metered: CloudWatch logs, metrics and alarms, billed per usage | Self-hosted cost: optional Logflare and Vector for analytics and logs, plus storage and any alerting you add | Recurring |
| Upgrades and operating time | Low internal effort: AWS manages the managed services | Staff time: applying Docker configuration releases, such as 0.8.3, and one-way Storage migrations that need a backup first; support is community-based | Recurring (staff time) |
| Migration and data export | One-time cost of exporting DynamoDB to S3, reshaping data into Postgres, and rewriting AppSync and Lambda code | One-time cost of building the Postgres schema, importing users and files, and cutover testing | One-time |
What moves the cost comparison most
Amplify costs scale with usage across several separately billed services, while self-hosted Supabase costs scale mostly with the servers and the people who run them. The drivers below show which side of the ledger each factor pushes, and what to measure before you compare totals.
Monthly active users
Amplify charges for Cognito, AppSync, Lambda and DynamoDB requests, so a growing user base raises several meters at once. On self-hosted Supabase, more users mostly means more load on the Postgres, Auth and Realtime services, which you size on fixed servers. Ask your team for a per-service usage breakdown by user tier so you can see which meter grows fastest. Verify the Supabase Docker minimum and recommended sizing against your expected load before you commit to hardware.
Data volume and growth
Storage and data transfer grow with the data you keep, and on Amplify they are billed per unit across DynamoDB, S3 and hosting. On self-hosted Supabase, growth consumes disk on the Postgres host and object storage you manage, so the 40 GB SSD minimum in the Docker guide is a floor, not a plan. Estimate growth per table and per bucket, then price the disk and backup capacity that growth requires.
Environments and preview builds
Every extra Amplify environment duplicates backend resources and build runs, and each preview build adds hosting build minutes. On self-hosted Supabase, a staging stack is another set of containers on servers you already pay for, though each one needs its own secrets and upgrades. Count the environments you need today and the preview builds per week, then decide whether staging shares hardware with production.
Availability requirements
Self-hosted Supabase runs as a single project, and its hosted features such as managed backups, point-in-time recovery and branching are not available when you self-host. Appwrite's Helm chart also runs its built-in datastores on a single replica without failover. If your service needs failover, you must add replicated Postgres, backups and monitoring, which raises the self-hosted side. Ask whether an outage on Amplify is an acceptable trade for your current service levels.
In-house operations skills
Amplify removes most server patching, upgrades and backup work from your team, and you pay for that inside usage charges. Self-hosted Supabase is community-supported, so questions about failures go to GitHub, Discord or Reddit unless you buy outside help. A team without Docker, Postgres and secrets management experience should budget for training or a support retainer, and the cost of that person's time is recurring. Assess each skill gap before you compare the two totals.
Release cadence
Self-hosted Supabase releases a Docker configuration that bundles specific Auth, PostgREST and Realtime versions, and some releases require a database backup before updating. Amplify ships platform changes on AWS's schedule, with no upgrade work on your side. Frequent self-hosted releases mean recurring engineering time for testing, staging and rollback, so plan a monthly or quarterly upgrade window and cost that effort into the self-hosted total.
How the self-hosted Supabase bill is built
The bill for self-hosted Supabase has two halves: the servers that run the Docker Compose stack and the people who keep it current. The stack includes Studio, an Envoy API gateway (Kong is optional), Auth (GoTrue), PostgREST, Realtime, Storage, imgproxy, postgres-meta, Postgres, the Edge Runtime on Deno, the Supavisor connection pooler, and optional Logflare and Vector for analytics and logs. The Docker guide gives minimum requirements of 4 GB RAM, 2 CPU cores and a 40 GB SSD, and recommends 8 GB RAM, 4 cores and 80 GB. Those figures are a starting point. Confirm them against your expected data volume, concurrent connections and whether you keep Realtime, Storage or Edge Runtime enabled, since the guide says unused services can be removed from docker-compose.yml.
Infrastructure is the recurring cost you can see on a cloud invoice. Upgrades are the cost you cannot. Envoy replaced Kong as the default gateway in 0.8.0 on August 11, 2026, and Postgres 17 has been the default since 0.6.0 on June 17, 2026. Each Docker configuration release also pins specific upstream services, for example Auth v2.197.0, PostgREST v14.18 and Realtime v2.143.3 in 0.8.3, so your team pulls and recreates those containers itself. Assign an owner for reading each changelog and rehearsing upgrades in a non-production copy. Budget that effort as recurring staff time, and ask any implementation partner to quote it separately from the one-time setup.
Version 0.8.3, released October 16, 2026, is the one to plan around first. Its changelog flags security fixes for Storage and Realtime and one-way Storage database migrations that require a database backup before you update. Treat the backup as a gate, not an optional step: take it, verify that you can restore it, and only then apply the change. Note also that self-hosted Supabase is community-supported and runs as a single project, so managed backups, point-in-time recovery and branching are not included. Your backup schedule, storage location and restore testing are therefore line items you must fund and staff yourself.
How to build the comparison with your own numbers
This sequence turns the cost components into a side-by-side model of your current Amplify spend and a self-hosted Supabase estimate, using your own usage and your own labor assumptions so the totals can be defended in a budget review.
Export twelve months of Amplify billing by service
The cloud account owner pulls the last 12 months of AWS billing for the Amplify app and its backend resources, grouped by service and usage type, from Cost Explorer or the detailed cost and usage report. Separate Amplify Hosting charges (build minutes, storage, data served and server-side rendering) from the separately billed Cognito, AppSync, DynamoDB, Lambda and S3 lines. The step is done when every line item in the bills maps to one of those categories and the total matches the invoices.
Tag usage to each cost component
Using the same export, the platform or FinOps owner attaches each cost line to a component: build minutes, hosted storage, data served, SSR, authentication, API requests, database capacity, functions and object storage. Where AWS does not separate usage by app, the team uses resource tags or an allocation rule and records it. The output is a table where each monthly figure has a component label and a note on how it was allocated, which lets a reviewer see what would disappear after a migration.
Measure the workload the backend must carry
The engineering lead records monthly active users, request volume, database size, file storage volume, peak concurrency and the number of functions that run per period, taken from Amplify metrics and application logs. These figures define the load the self-hosted stack must absorb. The check is a one-page workload sheet that a second engineer has reviewed for accuracy.
Size the Supabase footprint against documented minimums
The platform engineer compares the workload sheet with the minimum requirements in Supabase's Docker self-hosting guide, which lists 4 GB RAM, 2 CPU cores and a 40 GB SSD as the minimum and 8 GB RAM, 4 cores and 80 GB as the recommended configuration. Add headroom for growth, backups, a separate database host and any services you keep, such as Storage or Realtime. Confirm the instance prices for your provider and region in its own pricing pages. The output is a server list with monthly infrastructure cost per host.
Add the labor to install, upgrade and operate
The platform team estimates the hours for initial installation, hardening and secret management, routine Docker configuration updates, pulling upstream service versions, backup testing, monitoring and on-call coverage. Self-hosted Supabase is community-supported, so the team also prices any paid support, retainer or in-house expertise it needs. Record each labor line as one-time or recurring and state the hourly rate used. The output is a labor table that makes the staffing assumption visible.
Estimate one-time migration effort
Using the component mapping from earlier steps, the migration lead estimates the work to move data, users, files and functions, including the Firebase or Amplify export, user hash compatibility, rewriting resolvers or functions and cutover testing. Keep this as a separate one-time line so it does not distort the recurring comparison. The check is a written scope list with an hours estimate per item, reviewed by the team that will run the system.
Compare monthly and first-year totals on equal terms
The finance and engineering leads place Amplify's current monthly run cost next to the self-hosted monthly estimate, then add the one-time migration effort to build a first-year total for each option. Use the same growth, traffic and salary assumptions in both columns and show a sensitivity range for usage growth. The step is complete when the model lists every assumption, every source and the rates you confirmed on the AWS pricing pages, so a reviewer can change one input and see the effect.
Who supports the stack once it is yours
Self-hosted Supabase is community-supported. The self-hosting documentation names GitHub Discussions, GitHub Issues, Discord and Reddit as the support channels, and directs enterprises to contact Supabase's Growth Team for commercial arrangements. Once the stack runs in your own account, there is no bundled support contract that replaces the monthly Amplify bill, so the cost moves into your budget. Price it as one of three things: internal platform staff time, an external retainer, or a commercial agreement with Supabase. Ask Supabase's Growth Team in writing what it would cover and at what scope before you compare totals with Amplify.
Support also means keeping the Docker configuration current. The self-hosted Supabase Docker configuration is versioned separately from the upstream services it bundles. Version 0.8.3, released on October 16, 2026, pins Auth v2.197.0, PostgREST v14.18 and Realtime v2.143.3, and operators pull and recreate those containers themselves. The changelog flags security fixes for Storage and Realtime and one-way Storage database migrations that require a database backup before updating. Your team owns those patches, the backup beforehand and the test window, so budget recurring time for each release and a rehearsal in a non-production copy.
Confirm two things before you sign off on the estimate. First, who is on call for a Realtime or Storage incident at 2 a.m., and whether that rota exists today. Second, how long your team would need to apply a security release to the production stack, measured against your own change process rather than any vendor figure. Treat the answers as a risk register entry with an owner, not as an assumption buried in the operating cost. The Supabase self-hosting guide at Supabase self-hosting documentation is the place to check which services you need to keep patched.
Questions buyers ask before comparing Amplify and self-hosted Supabase
How much effort does moving from Amplify to self-hosted Supabase take?
The effort depends mainly on how much of your Amplify backend you actually use. Moving data and users is one part, while rewriting AppSync resolvers, Lambda functions and Cognito triggers into Supabase Auth, Postgres functions and Edge Functions is usually the larger part. Self-hosted Supabase is a set of Docker Compose services that includes Studio, an Envoy API gateway, Auth, PostgREST, Realtime, Storage, Postgres and Supavisor, so you also take on installing, upgrading and monitoring that stack. Ask any implementation partner to size the work from an inventory of your DynamoDB tables, Cognito pools, resolvers, functions and S3 buckets, and ask them to state the assumptions behind that estimate in writing.
How long does an Amplify to Supabase migration take?
Duration is set by data volume, the number of user accounts, how many backend features need rewriting and how much testing your app needs before cutover. No supplied figure gives a typical timeline, so treat any number you hear as a claim to verify against your own inventory. The factors that most often extend a schedule are password migration, since Cognito does not export passwords, the number of custom resolvers and triggers, and any compliance evidence you must produce along the way. Agree on a fixed scope and written deliverables before work starts, so the timeline follows from what is actually included.
What skills does the team need to run self-hosted Supabase?
Your team needs working knowledge of Docker Compose, Linux server administration, PostgreSQL and the Supabase services listed in the self-hosting guide. Someone must also own secrets, TLS, backups and upgrades. The self-hosting docs warn never to start with the placeholder values in .env.example and provide scripts to generate secrets and the JWT key pair, which is a good starting point but still needs an accountable owner. Upgrades matter because each Docker configuration release pins specific Auth, PostgREST and Realtime versions, and some releases require a database backup before updating. Check these skills against your staff before you commit to the move.
Can an in-house team run self-hosted Supabase without outside help?
Many in-house teams can run it, provided they have the skills above and accept that support is community-based. Supabase's self-hosting docs state that self-hosted Supabase is community-supported through GitHub Discussions, GitHub Issues, Discord and Reddit, and that enterprises should contact its Growth Team. Several features available on Supabase Cloud, including branching, managed backups, point-in-time recovery and the Management API, are not available when you self-host. Decide what you will do in-house, such as daily operations, and what you want to buy as retainer support, such as upgrades, testing and restore drills. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms in your own environment, with ongoing support available as a retainer.
How do I compare my Amplify usage with the cost of self-hosted servers?
Build the comparison from components rather than from a single total. On the Amplify side, list Hosting build minutes, storage, data served and SSR charges, then add the separately billed Cognito, AppSync, DynamoDB, Lambda and S3 usage from your AWS invoices for the last few months. On the self-hosted side, list the servers, storage, backups, monitoring, staff time for operations and upgrades, and any partner retainer. Supabase's minimum self-hosting requirements are 4 GB RAM, 2 CPU cores and a 40 GB SSD, with 8 GB RAM, 4 cores and 80 GB recommended, which gives you a sizing starting point. Ask any provider for a quote that separates one-time work from recurring costs and states what drives each line up or down.
Is cost the only reason to move from Amplify to self-hosted Supabase?
No, and a cost comparison alone rarely settles the decision. Common reasons include data residency, since you control where the database and files live, exit options if you want to avoid lock-in to AWS-specific services, and the ability to run the stack in a private network. These reasons come with trade-offs: you take on upgrades, backups and availability design that AWS currently handles for you. Consider whether you need Supabase's Postgres model at all, because the data model and auth flows change with the move. Ask whether the gains in control justify the operating work your team will carry.
When staying on Amplify is the lower-cost option
Amplify's metered model is often the cheaper choice when traffic is low or highly uneven, when no one on the team can run servers, and when the app has only one or two environments. In those cases the cost of a self-hosted Supabase stack is mostly fixed: a server or cluster that stays on whether or not anyone signs in, plus the hours needed to patch, back up and monitor it. Amplify charges for what is used, so a small internal tool with a few hundred users may cost less per month than a server that is always running. Before deciding, pull the last three to six months of usage from the AWS Cost Explorer for each Amplify component, separated by the Cognito, AppSync, DynamoDB, Lambda and S3 line items, and look at the peak month, not only the average.
The second condition is operational capacity. Self-hosted Supabase is community-supported according to its self-hosting documentation, so the team carries upgrades, security fixes and incident response itself. Supabase's Docker configuration releases pin specific Auth, PostgREST and Realtime versions, and a release such as 0.8.3 can include Storage migrations that are one-way and require a database backup first. If nobody on the team is willing to own that routine, the saving on the monthly bill may be offset by the time a developer spends on it. Ask who would perform each upgrade and how long the team has to do it before a security fix is due.
The third condition is the number of environments. Amplify creates a separate backend per branch or environment, and each one carries its own charges, so a team with development, staging, production and preview branches pays for each. A self-hosted stack also needs more than one instance to match that layout, but the cost of extra environments is mostly the infrastructure you already run. Count the environments you actually keep running and the number of preview deployments created each week. If the answer is one production backend and a single shared development environment, Amplify's model may stay competitive. Treat this as a check to run, not a conclusion, and confirm the figures against your own AWS invoices and the Supabase or Appwrite pricing pages before comparing totals.
How DeployOpen scopes a fixed-price Supabase implementation
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from AWS Amplify to self-hosted Supabase, the work starts with a written scope that separates what Amplify bills today from what your own servers and staff will carry.
How we scope
- Inventory the Amplify components in use: Hosting builds, SSR, Cognito, AppSync, DynamoDB, Lambda and S3
- Agree which data, users, files and functions move, and which stay on AWS during a transition
- Define the target servers, region and Supabase Docker release before any build work begins
- Document scope, deliverables and timelines in writing, since most engagements are fixed-scope
How we build
- Deploy self-hosted Supabase with Docker Compose, with secrets generated rather than left at placeholder values
- Reshape exported DynamoDB data into Postgres tables and map Cognito users into Supabase Auth
- Rebuild AppSync resolvers and Lambda logic as Postgres functions, Edge Functions or client code, as agreed in scope
- Copy S3 objects and test access rules, backups and restores against the agreed acceptance criteria
How we hand over
- Deliver runbooks for upgrades, including the backup step required before one-way Storage database migrations
- Document the cost components your team now pays for: servers, storage, backups, monitoring and staff time
- Record which hosted features, such as managed backups, point-in-time recovery and branching, are absent and what replaces them
- Walk your operators through restore testing so recovery steps are known before cutover
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Track Supabase Docker releases and service version pins so your team can plan each upgrade window
- Agree in the scope who answers incidents, since self-hosted Supabase relies on community channels by default
- Ask any provider, including DeployOpen, to confirm response expectations in the written agreement
