Which fits your AWS Amplify backend: Amplify or self-hosted Supabase
Amplify fits teams that have standardized on AWS and already run AppSync, DynamoDB, Cognito and Lambda, while self-hosted Supabase fits teams whose data is relational, whose code must stay portable, or whose data must sit on servers they control. If your main pressure is a renewal or an AWS bill that is hard to attribute across Cognito, AppSync, DynamoDB, Lambda and S3, the question is less whether AWS is expensive and more whether your application logic is tied to AWS-specific services. Amplify remains a sound choice when your organization has AWS operating practices, IAM governance and monitoring already in place, and your team benefits from AWS handling scaling of the managed services. Existing investment in AppSync resolvers and DynamoDB single-table designs is a real reason to stay, and the cost of rewriting it should be weighed against the savings.
Self-hosted Supabase fits when your data is naturally relational. Each Supabase project is a Postgres database, so tables, foreign keys, views and SQL migrations are standard assets that any Postgres team can read and move. Authorization in Supabase is expressed largely through Postgres row-level security, which means access rules live beside the data. Self-hosting also gives you control over where the stack runs, which matters when a data residency rule requires a specific facility. The trade-off is that you own the operation: the Docker Compose services, secrets, upgrades, backups and monitoring become your team's work. The Supabase self-hosting guide lists the services involved, and Supabase describes self-hosted installs as community-supported, so confirm what external support your contract includes.
The decision turns on three questions. First, the data model: map your DynamoDB access patterns to relational tables before you assume the move is straightforward. Second, auth migration: Cognito does not expose stored passwords, so confirm with your identity team whether users can be moved without a forced reset, or whether a reset flow is acceptable. Third, operating capacity: check whether your engineers can run Docker-based services with the upgrade, backup and security patching cadence that a self-hosted backend requires. If the answers point to a relational model, a clear auth path and a team ready to operate the stack, Supabase is a credible destination. If they do not, a staged approach that keeps Amplify for parts of the application until the data model is settled is often the safer route.
Which backend fits which scenario
This table matches common team situations to the platform that usually fits better, with the reason tied to the Amplify Gen 2 stack or to self-hosted Supabase's single-project, community-supported model. Read each row against your own constraints, and treat the answers as starting points to confirm in your environment.
| Scenario | Better fit | Reason |
|---|---|---|
| Team already standardized on AWS accounts, IAM and CDK | AWS Amplify Gen 2 | Cognito, AppSync, DynamoDB, Lambda and S3 are already governed by your AWS controls and billing, so staying avoids a second identity and data perimeter. |
| Team needs relational queries, joins and reporting | Self-hosted Supabase | Each project gets a Postgres database, so SQL joins, views and standard BI connectors work without reshaping DynamoDB access patterns. |
| Strict residency with servers in your own accounts or data centers | Self-hosted Supabase | Docker Compose runs in infrastructure you choose, so you control where Postgres, Storage and Auth data sit. Confirm the hosting details with your own environment. |
| Small team without platform engineers | AWS Amplify Gen 2 | Managed services handle patching and scaling, while Supabase self-hosting puts upgrades, backups and secrets on your team and is community-supported. |
| Team that wants the least migration work | AWS Amplify Gen 2 | Staying put avoids exporting DynamoDB, moving Cognito users and rewriting AppSync resolvers. A move is justified mainly by lock-in or cost concerns, not by migration effort. |
| Team that wants to avoid AppSync resolver lock-in | Self-hosted Supabase | Client queries run through PostgREST and SQL, so logic lives in Postgres and Edge Functions that you can move between servers. |
| Team with Cognito users and a need to keep password hashes | Confirm before deciding | Cognito does not expose passwords for export, so plan a reset or migration path first. Verify your user store and hash options with AWS and Supabase documentation. |
| Team that must run upgrades on a fixed schedule | Either, with a runbook | Supabase Docker releases bundle specific upstream service versions you pull and recreate yourself, so you need a tested upgrade and backup routine either way. |
How the data model and lock-in differ between Amplify and Supabase
An Amplify Gen 2 data model is defined in TypeScript on the AWS CDK and stored in DynamoDB, with AppSync resolvers and Lambda functions bound to AWS services. Models, authorization rules and relationships live in the backend code, and the runtime shape of the data follows DynamoDB's key-based access patterns. Teams that chose this model usually designed partition and sort keys around known queries. Before you plan an exit, confirm which resolvers, authorization modes and Lambda triggers your application depends on, and which of them only exist because AppSync sits in front of the tables.
Supabase gives each project a Postgres database, so tables, foreign keys, views and migrations are standard SQL that any Postgres host can run. Access control sits in the database as row-level security policies, and the API layer (PostgREST for the REST interface, with Realtime for change events) reads the same schema. The trade-off is modeling work. Data that was shaped for DynamoDB's single-table patterns usually needs to be normalized into relational tables, and that reshaping is an engineering task your team should estimate with the migration plan, not after cutover.
Lock-in is mostly about the code you must rewrite on exit, not only the data. Exporting DynamoDB items or Cognito users moves the records, but the CDK stacks, AppSync schemas, resolvers and Lambda handlers have to be replaced with Postgres queries, policies and Edge Functions or your own services. Ask your team to inventory every Amplify-specific API call in the frontend and every resolver in the backend, then decide which access rules move into Postgres policies. That inventory tells you how much of the application is portable before you commit to a timeline.
Capabilities side by side: Amplify Gen 2 and self-hosted Supabase
This table maps each Amplify Gen 2 capability to its closest self-hosted Supabase component and marks where the match is partial or missing. Read the cells as a starting point for your own feature checklist, since Amplify coverage changes and should be confirmed in AWS documentation for your region and configuration. The main takeaway is that Supabase replaces most of the application-facing services, but operating its backup, recovery and support model becomes your responsibility.
| Capability | AWS Amplify Gen 2 | Self-hosted Supabase |
|---|---|---|
| Authentication | Cognito user pools, defined in TypeScript and deployed through the CDK; confirm MFA and federation options in AWS docs | Supabase Auth (GoTrue), built into the Docker Compose stack; imported password hashes need compatibility checks |
| Client database | AppSync GraphQL API over DynamoDB tables; access rules set in the schema and resolvers | PostgREST exposing Postgres 17 tables over HTTP, with row-level security policies on the database itself |
| Functions | Lambda functions wired to AppSync or triggers, billed per invocation and duration | Edge Runtime on Deno inside the stack; confirm the runtime and limits suit your workloads before migrating |
| Realtime | AppSync subscriptions over WebSockets, managed by AWS | Supabase Realtime service, pinned to a specific upstream version in each Docker configuration release |
| File storage | S3 buckets with access rules defined in the Amplify backend | Supabase Storage with imgproxy for image transforms; you operate the underlying object store |
| Hosting | Amplify Hosting builds, CDN and server-side rendering for web front ends | No built-in hosting; front ends run on your own servers or on a separate tool such as Coolify or Dokploy |
| Backups and recovery | Managed by AWS services such as DynamoDB point-in-time recovery; confirm settings per table | Self-hosted Supabase does not offer managed backups or point-in-time recovery; you must build and test them |
| Licensing | Proprietary managed services billed separately per AWS service | Apache-2.0 license for the Supabase repository; you still need to plan support, since self-hosting is community-supported |
Where your data lives and who runs it
An Amplify Gen 2 backend is provisioned into your AWS account and spread across Cognito, AppSync, DynamoDB, Lambda and S3. Data location is therefore a question of the AWS region you choose for each resource, and AWS operates the underlying infrastructure under its shared responsibility model. Your team controls IAM policies, KMS keys and region selection, but the managed services themselves are run by AWS.
- Region per resource: Cognito user pools, DynamoDB tables and S3 buckets are created in regions you select in the CDK definition, so confirm each one matches your residency rules.
- Managed encryption keys: Encryption at rest uses AWS-managed or customer-managed KMS keys, and the key policy decides who can decrypt.
- Shared responsibility: AWS runs the hardware, hypervisors and managed service software, while your team owns IAM, bucket policies and application logic.
- Compliance evidence: AWS publishes its own compliance reports, which you can request, but your application-level controls need separate evidence.
- Service sprawl: Data is spread across five services, so a data map must cover each store and its access paths.
Before relying on this model, confirm with AWS which services and regions your residency and audit scope require, and ask your assessor which evidence they accept for managed services.
Supabase Cloud is the hosted platform run by Supabase. Each project is hosted in one main region, chosen when the project is created from 17 AWS regions, and the database, auth, storage and API layers run on Supabase's platform. Your data residency is therefore set by a single regional choice, but operation, patching and backups belong to Supabase.
- One main region: Choose the region at project creation, because the main region is the location your primary data is hosted in, and confirm it against your residency commitments.
- Hosted operations: Supabase manages upgrades, backups and point-in-time recovery on hosted plans, which the self-hosted edition does not include.
- Vendor access controls: Ask Supabase how staff access to customer projects is logged and restricted, and request the documentation for it.
- Plan-dependent features: Some controls and support terms differ by plan, so confirm them against the plan you would buy.
- Subprocessors and contracts: Review the data processing terms and the list of subprocessors before signing.
Ask Supabase in writing which region options and backup locations apply to your project, and request its current security and compliance documentation for your assessor.
Self-hosted Supabase runs as Docker Compose services in your infrastructure, so your team decides where data is stored, who can reach the servers and how keys are issued. The services include Studio, an Envoy API gateway, Auth, PostgREST, Realtime, Storage and Postgres, along with optional analytics components. Control is high, but operating responsibility moves to your team, and Supabase describes self-hosted support as community-supported.
- Secrets before first start: The guide warns never to start with the placeholder values in
.env.example, so generate secrets with the provided scripts and store them in your secrets manager. - Studio protection: Set
DASHBOARD_PASSWORDto protect Studio with HTTP basic auth, and place Studio behind your own network controls or single sign-on proxy. - Single project scope: Self-hosted Supabase runs as a single project, and features such as managed backups and point-in-time recovery are not available, so plan your own backup and restore testing.
- Key ownership: Your team holds the JWT key pair and database credentials, and you control rotation and access logs.
- Evidence you produce: Keep configuration records, secret rotation logs, patch records and restore tests as the evidence an auditor will request.
DeployOpen can prepare these controls and the supporting evidence for your compliance assessment, but it does not issue audit reports, attestations or certifications. Confirm with your assessor which controls and evidence they will test.
What running self-hosted Supabase means day to day
Before committing to self-hosted Supabase, the first decision is whether your team will operate a multi-service stack. The Docker Compose configuration, published in the docker directory of the supabase/supabase repository, runs Studio, an Envoy API gateway (Kong is optional), Auth (GoTrue), PostgREST, Realtime, Storage, imgproxy, postgres-meta, Postgres, the Edge Runtime on Deno and the Supavisor connection pooler, with optional Logflare and Vector for analytics and logs. Each of these replaces a piece you currently get from Cognito, AppSync, Lambda or S3, so you own the upgrade and failure path for every one. The guide says unused services such as Realtime, Storage, imgproxy or Edge Runtime can be removed from docker-compose.yml, which is worth deciding in the design phase rather than after go-live. The guide's minimum is 4 GB RAM, 2 CPU cores and a 40 GB SSD, and its recommendation is 8 GB RAM, 4 cores and 80 GB. Confirm the storage growth of your Storage bucket and database before sizing, because the 40 GB floor is a starting point, not a capacity plan.
Self-hosted Supabase runs as a single project. Studio does not manage multiple organizations or projects, and branching, managed backups, point-in-time recovery, the Management API, ETL and advanced metrics are not available, according to the self-hosting docs. If your Amplify setup relies on separate dev and prod environments, plan a second self-managed stack or a documented promotion process, and make your own backup schedule and restore test part of the runbook. Each Docker configuration release also pins upstream versions: 0.8.3, released on October 16, 2026, bundles Auth v2.197.0, PostgREST v14.18 and Realtime v2.143.3. Operators pull and recreate those images themselves. The changelog flags security fixes for Storage and Realtime and one-way Storage database migrations that require a database backup before updating, so read the Supabase self-hosted Docker changelog before every upgrade and take a backup first.
Cost components on each side, and what drives them
An Amplify backend bills in several places at once, and a self-hosted Supabase stack moves the cost onto servers, backups and the people who operate them. The cards below separate those components so you can compare like with like before you request quotes.
Amplify usage charges
AWS bills Amplify Hosting for build minutes, stored assets, data served and server-side rendering, and each of those scales with traffic and deploy frequency. Ask AWS for a usage estimate based on your own build count, peak requests and asset footprint, because published unit rates alone will not tell you the monthly total. Recurring charges are the main driver to watch.
Separately billed backend services
Cognito, AppSync, DynamoDB, Lambda and S3 are each metered on their own, so a single user action can touch several bills. Check how many requests, reads, writes, invocations and stored objects your app generates per user, since these multiply as the user base grows. Your AWS account team or cost tools can break this down by service.
Servers and cloud instances
A self-hosted Supabase stack runs as Docker services on servers or cloud instances you provision, so you pay your infrastructure provider on a recurring basis regardless of request volume. Supabase's self-hosting guide lists minimum requirements of 4 GB RAM, 2 CPU cores and a 40 GB SSD, with 8 GB RAM, 4 cores and 80 GB recommended. Size against your load test results, not those minimums alone.
Backups and recovery you run
Managed backups and point-in-time recovery are not available in self-hosted Supabase, so you pay for backup storage, the tooling that takes database and object backups, and restore testing. This is a recurring cost plus a one-time setup. Ask your team who owns restores and how long a restore takes in your environment, because those answers set the cost of a failed upgrade.
Engineering time to upgrade and monitor
Self-hosted Supabase releases arrive often, and some configuration changes, such as one-way Storage database migrations, require a database backup before updating. Budget recurring engineering hours for upgrades, security patches, monitoring and on-call, since Supabase's self-hosting docs describe community support rather than a support contract. This is usually the largest self-hosted cost line.
Optional DeployOpen implementation
DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your infrastructure under a fixed scope agreed in writing before work starts. It is a one-time cost when the migration is delivered, and ongoing support or upgrades are available as a separate retainer. A quote follows from your written scope, so ask for the deliverables, the environments covered and what the retainer excludes.
How a move from Amplify to self-hosted Supabase proceeds
The sequence below takes an Amplify Gen 2 backend to a self-hosted Supabase stack in your own infrastructure, with each step ending in a check that proves the previous one is complete. It is ordered so that data, identity and files are settled before any traffic moves.
Inventory the Gen 2 backend and CDK code
Someone on the engineering team lists every backend resource defined in the Amplify project: the data schema, auth configuration, storage buckets, AppSync API, Lambda functions and any custom CDK constructs, plus the frontend calls that reach each one. The output is a written inventory that maps each resource to its future Supabase equivalent or to a decision to drop it. You know this step is done when every client call in the app traces to a line in that inventory.
Design the Postgres schema and reshape DynamoDB data
Your data engineers and backend developers translate the DynamoDB single-table or multi-table design into normalized Postgres tables, with keys, foreign keys, indexes and the row-level security policies that replace Amplify's owner and group authorization rules. Export tables from DynamoDB as described in the export guide, then test the transformation on a copy of the data. The step closes when a reshaped sample of each table loads into a development Postgres database and the application's core queries return the same results as before.
Plan the Cognito user migration
Identity owners confirm which sign-in methods are in use, then decide how users move to Supabase Auth. Cognito does not expose password hashes through ListUsers, so you cannot carry passwords over directly. Options to evaluate include forcing a password reset on first sign-in, or a staged login flow that verifies users against Cognito during a transition period. The step is done when the chosen approach is written down, approved by the security owner, and tested with a small set of test accounts.
Rewrite AppSync resolvers and Lambda functions
Developers translate each AppSync resolver and Lambda handler into a Postgres function, a database trigger, or a Supabase Edge Function, depending on whether the logic belongs close to the data or needs external calls. Each rewritten piece is reviewed against its original behavior, including input validation and authorization checks that Amplify previously enforced. The step is complete when every item in the inventory has a replacement and a test that exercises it.
Copy S3 objects to Supabase Storage
The team copies stored files from the Amplify S3 buckets into Supabase Storage buckets, recreates the access policies, and updates object references in the database to the new paths. The copy procedure should be verified with checksums or object counts against the source. The step is finished when a sample of files downloads correctly through the application with the same permissions as before.
Deploy self-hosted Supabase with hardened secrets
Platform engineers deploy the Docker Compose configuration in your own cloud account or data center. Before first start, they replace every placeholder value in the environment file with generated secrets, generate the JWT key pair with the provided scripts, and protect Studio with a strong dashboard password. They also confirm backups, network access rules and log retention. The step is done when a security review confirms no default secrets remain and a restore from a backup has been tested in a non-production environment.
Test with parallel runs
Run the Amplify backend and the Supabase stack side by side against the same test cases, including authentication flows, reads and writes, file access and background jobs. Compare results and resolve differences in data, permissions and timing. Realtime behavior and authorization edge cases deserve particular attention because they are the most common sources of mismatch. The step closes when the test suite passes on both stacks and a designated owner signs off on the differences that remain.
Cut over and confirm the exit
The team freezes writes on the Amplify backend, runs a final data export and import, switches the application's endpoints and keys to the self-hosted Supabase project, and monitors errors and sign-ins closely. Once traffic is stable, the Amplify resources are retained for a defined rollback period before deletion, and the decommissioning is recorded. The step is complete when the application runs entirely on Supabase, the final export is archived, and the Amplify resources are scheduled for removal with an owner assigned.
Questions buyers ask before choosing Amplify or Supabase
How much does self-hosted Supabase cost compared with AWS Amplify?
No single figure settles this, because the two bills are built differently. Amplify charges separately for hosting, build minutes, data served, and each service behind the Gen 2 backend, including Cognito, AppSync, DynamoDB, Lambda and S3, so usage in each service adds to the total. Self-hosted Supabase replaces that with servers or cloud instances you pay for directly, plus storage, backups, monitoring, and the engineering time to patch and operate the stack. Ask for a quote that lists each component, the expected monthly usage you used to size it, and who carries the on-call and upgrade work. Supabase's pricing page covers its hosted plans only, so compare self-hosting against your own infrastructure costs, not that page.
How long does migrating from Amplify to Supabase take?
The duration depends on three things: how many tables and relationships the DynamoDB model needs reshaped into Postgres, how many users sit in Cognito, and how many AppSync resolvers and Lambda functions must be rewritten. A small app with a simple schema and a few functions differs greatly from a multi-tenant product with complex access rules. No timeline is safe to state before those counts are known. Ask for a scoped plan that lists the tables, users, functions and files in scope, the cutover approach, and the acceptance tests. DeployOpen agrees scope, deliverables and timelines in writing before work starts.
Can our team run self-hosted Supabase without outside help?
A team can run it in-house if it already operates Docker, Postgres and TLS certificates, and has an owner for secrets, backups and upgrades. Supabase's self-hosting guide names Docker Compose as the recommended method, and self-hosted Supabase is community-supported through GitHub Discussions, GitHub Issues, Discord and Reddit, with enterprises directed to Supabase's Growth Team. That means there is no included support SLA on the self-hosted path, so your team owns incident response. Check whether you have someone who can read Postgres logs, restore a backup and apply a release with database migrations, which the changelog says can be one-way for Storage. If those skills are thin, a retainer for upgrades and monitoring is an option.
What does migrating Cognito users involve, and do passwords move?
Cognito does not let you export user passwords, so they cannot be carried over to Supabase as stored hashes. The Firebase-style approach, where hash parameters are exported and reused, does not apply to Cognito. In practice, teams move the user profile and attributes through the Cognito ListUsers API, then either send password reset links or add a bridge that asks users to confirm their identity at first sign-in. Plan for a period where some users must reset, and decide how you will notify them and handle users who never return. Confirm the attributes, custom fields and group memberships you need to keep, since they are the part that does transfer cleanly.
Does Supabase cover realtime and functions the way AppSync does?
Supabase covers the same categories through different parts. Realtime broadcasts database changes and messages to subscribed clients, and the self-hosted Docker stack includes a Realtime service. Edge Runtime on Deno runs server-side functions, where Lambda and AppSync resolvers currently handle the logic. The differences matter in the details. AppSync gives you managed GraphQL with subscriptions tied to the data source, while Supabase's API is built on PostgREST and client subscriptions work through its own libraries, so GraphQL schemas and resolvers will need to be rewritten. Load behavior, connection limits and error handling must be tested on your own servers, because self-hosting moves those limits under your control.
What is the difference in data model and lock-in risk?
Amplify stores most application data in DynamoDB, a key-value store with access patterns designed around its partition keys, while Supabase gives each project a Postgres database that you can query with standard SQL. The move therefore means redesigning access patterns as relational tables, which is the largest engineering item in most migrations. On lock-in, the Supabase stack is Apache-2.0 and the database is standard Postgres, so the data stays portable. Amplify's backend is defined as TypeScript on the AWS CDK, and the resources sit in your AWS account, so exit also means exporting DynamoDB data (which needs point-in-time recovery enabled), S3 objects and code.
What does a DeployOpen engagement need from us?
DeployOpen works on fixed-scope engagements, so the first step is a written scope that names the data model decisions, the users and functions to move, and the environments to build. You will need to give access to the AWS account or a read-only export path, a named technical owner, and time for decisions on schema, auth flows and access rules. DeployOpen plans, implements, hardens, backs up, documents and supports the self-hosted platform inside your own cloud accounts or data centers. It does not issue audit reports or certifications. Compliance readiness work produces the controls and evidence, and independent auditors make the assessment. Ask for a quote built from the written scope.
When staying on Amplify is the better decision
Staying on Amplify is the better decision when the cost of moving the data layer is higher than the cost of the problems you are trying to solve. The clearest case is a team whose application data already lives in DynamoDB, whose access rules are written as AppSync authorization modes and resolvers, and whose operators already run IAM, Cognito and CloudWatch as a standard part of their estate. In that situation, a Postgres rewrite of the data model, the access policies and the client queries is a large one-time project, and the gain is mostly portability rather than a change in what the app does. Before deciding, list every AppSync resolver and every DynamoDB access pattern and ask whether a Postgres schema with row-level security would express them more simply, or only differently.
A second case is a team without the capacity to run stateful services. Self-hosted Supabase runs Postgres, Auth, Realtime, Storage and the rest as Docker Compose services that you update and back up yourselves, and Supabase's self-hosting docs describe the setup as community-supported. If nobody on the team can own database backups, restores and upgrades, Amplify's managed operation is a real advantage, and that cost does not disappear when you leave AWS. Confirm who will carry on-call duty for the database and how restores will be tested before treating self-hosting as cheaper.
A middle path often gives most of the benefit with less risk: keep Amplify Hosting for the front end and build pipeline, and change only the data layer or the authentication layer when a specific problem justifies it. For example, a team could keep Amplify-managed deployments while moving a single high-value dataset to a self-hosted Postgres instance, or keep Cognito while evaluating whether the app's sign-in flows can move later. Write down which of the four problems you are solving (cost visibility, lock-in, data residency or a Firebase-style exit) and move only the layer that addresses it.
How DeployOpen helps you evaluate and move
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an Amplify to Supabase decision, we start with a written scope that tests your actual Amplify backend against the self-hosted Supabase stack before any migration work begins.
How we scope
- Inventory the Amplify Gen 2 backend, including the TypeScript and CDK definitions for Cognito, AppSync, DynamoDB, Lambda and S3
- Agree in writing which data models, auth flows, functions and realtime features move to Postgres and which are rebuilt
- Confirm where data must reside, since self-hosted Supabase runs in the region and infrastructure you choose
How we build
- Deploy self-hosted Supabase with Docker Compose in your environment, replacing placeholder secrets and protecting Studio access
- Map DynamoDB tables to Postgres schemas and rewrite AppSync resolvers and Lambda handlers as functions and row-level security policies
- Plan Cognito user migration and confirm password hash handling with your identity team before any user is moved
How we hand over
- Document the deployed architecture, configuration, secret handling, backup schedule and upgrade procedure for your operations staff
- Test restores from backup and run security testing of the application, API and infrastructure before go-live
- Deliver evidence and runbooks that your compliance team can use in its own assessments, without us issuing any audit or certification
How we support
- Support engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Ask for a quote built from the written scope, since DeployOpen does not publish a price list
