What World Cup sportsbook attacks and game-launch outages have in common

The direction that proves whether a migration practice is actually vendor-neutral: why some teams leave Supabase, and what really happens when they do. We've spent the last several articles walking through why teams move to Supabase — from Firebase, Amazon RDS, Neon, Heroku, Render, and legacy MySQL/MSSQL systems. If that's all we ever wrote about, it would be fair to wonder whether we're vendor-neutral migration engineers or just a Supabase sales channel with extra steps. So it's worth covering the direction that actually proves the point: why do teams migrate away from Supabase, and what does that migration look like? The honest answer is that leaving isn't a failure state, for Supabase or for the team leaving. Postgres is Postgres wherever it runs, and a platform that's genuinely open about that fact should make leaving straightforward when it's the right call. This guide covers the real reasons teams do it and exactly what happens technically when they do. Why teams actually migrate away from Supabase Need for serverless scale-to-zero — Neon's specialization Supabase's compute model isn't built around scaling to zero the way Neon's storage/compute-separated architecture is. For a steady production workload, that's rarely the deciding factor. But for spiky, intermittent usage — a staging environment that's live a few hours a day, a fleet of preview branches for CI that sit idle most of the time — paying for always-on compute is a real, avoidable cost. Teams with this specific usage pattern sometimes move the non-production parts of their infrastructure to a platform built around that exact economics, while keeping production wherever makes sense. Not wanting the whole bundle in the first place Some teams adopt Supabase for the Postgres database and the speed of getting started, and later realize they never actually wanted the bundled Auth and generated API layer — they want a clean Postgres instance with their own custom authentication (Auth.js, Better Auth, a hand-rolled system) and their own API design. This isn't a complaint about Supabase doing anything wrong; it's a mismatch between what the platform optimizes for and what a specific team's architecture actually needs once it's mature enough to have strong opinions about its own Auth and API layer. Extreme scale: compute cost and data residency At a large enough scale, two things tend to surface. First, compute cost optimization becomes worth dedicated engineering attention in a way it isn't for a smaller application — and that sometimes means a different hosting arrangement makes more financial sense than a managed platform's standard pricing. Second, data-residency requirements can extend beyond the regions Supabase supports directly, particularly for regulated industries or specific national compliance requirements. Neither of these is a criticism of Supabase — they're the kind of constraints that show up specifically at a scale most projects never reach. Wanting fully self-managed infrastructure This is worth calling out as a special case, because it's not really a departure at all. Teams that want complete control over their infrastructure — their own Kubernetes cluster, their own backup strategy, deployment inside their existing cloud environment for compliance reasons — aren't leaving Supabase as a platform. They're choosing self-hosted Supabase, which is a fully supported, open-source deployment model, not a different product. If this is your reason for "migrating away," the honest framing is that you're moving to a different deployment of the same platform, and it's worth reading that as a distinct project from the other three reasons on this list. What actually happens when you leave Supabase The database: still just Postgres, in both directions This is the same fact that's made every migration to Supabase in this series comparatively low-risk, and it holds in reverse: because Supabase runs standard Postgres with no proprietary storage format, the same pg_dump/pg_restore tooling that moves data in also moves it back out. pg_dump -h db.xxxxxxxxxxxx.supabase.co -U postgres \ -d postgres -Fc -f supabase_dump.dump pg_restore -h your-new-host -U postgres \ -d your_database --no-owner --no-privileges supabase_dump.dump There's no vendor-specific export format to fight, no data trapped behind an API that only Supabase's own tools can read. Whatever you think of Supabase as a platform, this part of its architecture does what open standards are supposed to do. Auth: easier to extract than you'd expect, harder to land This is the detail most teams get wrong in both directions, so it's worth being precise. Supabase Auth stores password hashes using bcrypt, in the encrypted_password column of the auth.users table — which is a normal Postgres table inside a database you fully control. Unlike a platform such as AWS Cognito, which explicitly blocks password hash export via its API for security reasons, there's no equivalent restriction here: if you have direct database access to your own project (which every Supabase project owner does), the hashes are just sitting in a table you can query. The harder part isn't extraction — it's whether your destination can use what you extract. If you're moving to another bcrypt-based Auth system, this is close to a direct transfer. If you're moving to a system that hashes with a different algorithm by default (Better Auth's default is scrypt, for example), you have two real options: configure the destination to verify against bcrypt for migrated users, or run a gradual migration where each user's password gets re-hashed in the new system's format the next time they successfully log in. Both are well-documented patterns, not open research problems. One more detail worth knowing: each Supabase project has its own JWT secret used to sign session tokens. If you carry that secret over to wherever you're going, existing sessions stay valid. If you don't, users need to sign in again — which is a minor inconvenience, not a password reset. Storage: S3-compatible, straightforward to move Because Supabase Storage exposes an S3-compatible API — the same fact that makes migrating storage into Supabase from an existing S3 bucket comparatively easy — moving files back out works the same way in reverse. Standard S3 tooling (the AWS CLI, rclone) can read directly from Supabase Storage and copy objects to wherever you're headed next. Access-control policies, which live as Storage RLS in Supabase, need to be re-expressed in whatever access-control model your destination uses. Realtime and Edge Functions: rebuilt, not exported This is where a genuine rebuild is unavoidable. Supabase Realtime is built on Postgres's logical replication; whatever platform you're moving to almost certainly implements realtime updates differently, so the client-side subscription code needs to be rewritten against the new system's API. Edge Functions run on Deno specifically — if your destination doesn't support Deno natively, those functions need to be ported to whatever runtime you're moving to, function by function, based on what each one actually does rather than a mechanical translation. How complex is migrating away from Supabase, really? Component Complexity Why Database (schema + data) Low Standard Postgres with no proprietary format; pg_dump/pg_restore works in both directions Authentication Moderate Password hashes are directly accessible via SQL (unlike Cognito); destination compatibility, not extraction, is the real variable Storage Low S3-compatible API means standard S3 tooling works directly; only access-control policies need re-expressing Realtime & Edge Functions Moderate–High No direct equivalent on most destination platforms; client code and functions need genuine rebuilding, not translation An important reframe: this isn't always a lost client Here's the part worth being direct about, because it changes how this whole topic should be read. Of the four reasons teams migrate away from Supabase, one of them — wanting fully self-managed infrastructure — isn't actually a departure. It's a request for self-hosted Supabase, deployed inside a client's own AWS, GCP, or Azure account, with the same Postgres, Auth, Storage, and Realtime stack, just running somewhere the client fully controls. That's not a competing outcome to the migration work we've described throughout this series — it's a direct match for one of our core services. A client who says "we want to leave Supabase because we need self-managed infrastructure" is, more often than not, a client whose actual need is met by staying on the platform and changing where it runs. Recognizing that distinction early is one of the more valuable things a migration partner can catch before a team spends effort moving somewhere they didn't need to go. Common pitfalls we see Assuming Auth hashes can't be extracted, and planning a mass password reset unnecessarily. Because the bcrypt hashes are sitting in a normal Postgres table you control, a forced reset is often avoidable — but only if the migration plan accounts for hash-format compatibility with the destination from the start. Treating "we want self-hosted" and "we want to leave Supabase" as the same project. They frequently aren't. Scoping which one you're actually facing changes the entire plan. Underestimating the Realtime and Edge Function rebuild. The database migrating cleanly can create a false sense that the whole project is low-risk; the parts of Supabase that don't have a direct equivalent elsewhere are where the real engineering time goes. Not carrying over the JWT secret when it matters. A minor detail that determines whether users get a slightly awkward "please sign in again" moment or a seamless transition. A quick pre-migration checklist Which of the four reasons actually describes your situation — and specifically, is "self-managed infrastructure" really a platform departure, or a case for self-hosted Supabase instead? What password hashing algorithm does your destination Auth system use by default? This determines whether Auth migration is a near-direct transfer or requires a gradual re-hash-on-login approach. Do you need existing user sessions to remain valid, or is an occasional re-login acceptable? This determines whether carrying over the JWT secret is worth the extra step. How much of your application depends on Supabase Realtime or Edge Functions, and does your destination platform have a genuine equivalent or does that logic need a real rebuild? Are you moving for cost, control, or a specific technical capability (like Neon's scale-to-zero)? The answer shapes whether this is a full migration or a partial one. 🔄 Not sure if you need to leave Supabase, or just change how it's deployed? Gart Solutions scopes migrations in either direction — including the self-hosted Supabase option that solves more "we want to leave" conversations than you'd expect. See how our migration practice works → How Gart Solutions approaches these migrations Migrating away from Supabase gets the same discipline we bring to every migration in this series, with one addition specific to this direction: we start by confirming which of the underlying reasons is actually driving the request, because "self-managed infrastructure" and "leave the platform entirely" point to very different projects. Our process typically covers: Scoping the real destination — distinguishing a genuine platform departure from a case for self-hosted Supabase before any migration work begins Database migration — pg_dump/pg_restore, validated against schema and row counts, in either direction Auth migration strategy — direct hash transfer where the destination's hashing algorithm is compatible, or a gradual re-hash-on-login approach where it isn't Realtime and Edge Function rebuilds — reimplemented against the destination platform's actual capabilities, not mechanically translated This completes the picture for what we've covered across this series: we handle migrations of any complexity, in any direction, across the Postgres and BaaS ecosystem. Firebase, Amazon RDS, Neon, Heroku, Render, and legacy MySQL/MSSQL systems onto Supabase — and Supabase onward to wherever a client's architecture actually needs to go next. The direction of the arrow has never been the point; getting the migration right has. Conclusion Teams leave Supabase for real, specific reasons — spiky workload economics, wanting a leaner unbundled stack, extreme-scale cost or residency requirements, or a need for full infrastructure control. None of those reasons make Supabase the wrong choice in general; they're the kind of requirements that only show up once a project has grown into them. The database migration itself stays genuinely low-risk in either direction, because Postgres doesn't lock your data into a proprietary format. What deserves real attention is Auth compatibility with your destination and the Realtime/Edge Function rebuild — and, just as importantly, confirming upfront whether "leaving" actually means leaving, or just means self-hosting the same platform somewhere you control. Planning a Supabase or Postgres migration? Gart Solutions' database migration engineers plan and execute Postgres migrations — into Supabase, within a live schema, or off a managed platform entirely — with a rollback plan built in from day one, not bolted on after something breaks. 40% cost reduction on a comparable Postgres migration 25% query performance improvement Minimal downtime during cutover Database Migration Cloud Migration SRE & Monitoring Compliance Audit Talk to a migration engineer  →

Why teams move past Render's database-only model, the specific limits worth knowing about, and how simple the underlying migration actually is. Render earned its reputation as the platform a lot of teams moved to after Heroku's free tier disappeared in 2022 — modern dashboard, Git-based deploys, genuinely useful free static hosting. For plenty of projects, it's still a good fit. But teams that reach for Render specifically for its Postgres offering run into the same structural gap we've covered for other managed-database platforms in this series: Render gives you a database. It doesn't give you a backend. This guide covers why teams move from Render to Supabase, where Render's Postgres offering has real, specific limitations worth knowing about, and how simple the underlying database migration actually is. TL;DR Render Postgres is a managed database and nothing more — Auth, Storage, and Realtime all have to be sourced and integrated separately. Render's free Postgres tier is genuinely time-limited: it expires 30 days after creation with no grace period, and paid tiers don't include connection pooling at any level. Teams increasingly want to consolidate their stack onto one platform instead of managing a database provider plus separate services around it. Migration complexity is low: Render Postgres and Supabase are both standard Postgres, and the official path is pg_dump/psql — the same well-tooled route as a Heroku migration. Gart Solutions plans and executes migrations of any complexity — from Render specifically, and from the wider Postgres and BaaS ecosystem more broadly. Why teams are leaving Render for Supabase Render Postgres is a managed database — and only that Render's core pitch is deployment simplicity: connect a Git repository, and Render figures out the runtime, builds it, and gives you a live URL with HTTPS, no Dockerfile required. That's genuinely good developer experience for the compute side. The Postgres offering that sits alongside it is a solid managed database — but it's exactly that and nothing more. There's no bundled authentication, no file storage, no realtime layer. Every one of those still has to come from somewhere else, the same way it would with any standalone managed Postgres provider. The free tier has a harder edge than it first appears It's worth being specific here, because the details matter for planning. Render's free Postgres tier gives you a 256MB, 1GB-storage database — and it expires 30 days after creation, with no grace period. When it expires, Render deletes the database and everything in it; there's no automatic migration, no freeze option, no recovery path. That's a meaningfully harder cutoff than a platform that just raises prices or nags you to upgrade — it's a countdown with data loss at the end if you don't act. Beyond the free tier, there are structural gaps worth knowing about even on paid Render Postgres plans: connection pooling isn't included at any tier, which matters more than it sounds for applications with bursty or serverless connection patterns, and high availability is gated behind a considerably more expensive tier. None of this makes Render Postgres a bad database — it's a legitimate, competent managed Postgres offering. But it's a narrower one than teams sometimes expect once they're relying on it for something real. Wanting one platform instead of a database plus separate services The pattern here is the same one we've described for other database-only sources in this series: a project starts with Render Postgres because the team wants a straightforward managed database, and over time ends up sourcing authentication, file storage, and realtime updates from separate places — a third-party Auth provider, an S3-compatible bucket, maybe a dedicated realtime service. Each addition is reasonable in isolation. Collectively, it's a hand-assembled backend platform, and at some point the operational cost of maintaining several separate services outweighs whatever specific advantage kept them separate in the first place. What actually happens during a Render to Supabase migration The database: pg_dump/psql, same as Heroku This is the straightforward part, and it deserves to be stated plainly: because Render Postgres and Supabase are both standard Postgres, migrating the database itself follows the same well-documented path as a Heroku migration. There's no dialect conversion, no schema redesign — just a database move using tooling every Postgres-experienced team already knows: # Dump from Render (connection details from the Render dashboard's Connect menu) pg_dump --clean --if-exists --quote-all-identifiers \ -h $RENDER_HOST -U $RENDER_USER -d $RENDER_DATABASE \ --no-owner --no-privileges > render_dump.sql # Restore into Supabase psql -h db.xxxxxxxxxxxx.supabase.co -U postgres -f render_dump.sql Supabase publishes an official migration guide for Render specifically, following this same pattern. For most projects, this is the entire database migration — schema, data, indexes, and constraints move over intact. Auth, Storage, and Realtime: a green-field decision, not a forced migration Because Render never bundled these services, what you're migrating away from depends entirely on what your team already built. If there's no real authentication system yet, adopting Supabase Auth is a green-field integration. If there's an existing third-party Auth provider, storage bucket, or realtime service already in place, none of that is required to change as part of the database migration — those become optional consolidation decisions, made deliberately, rather than something the migration forces on day one. Connection pooling: a genuine upgrade, not just a lateral move This is worth calling out specifically because it's an area where the migration is a real improvement, not just a change. Supabase includes connection pooling (via Supavisor) as part of the platform, which matters in particular for serverless functions and edge deployments that open and close many short-lived database connections — exactly the pattern where the absence of pooling on Render Postgres becomes a practical problem rather than a theoretical one. Teams migrating from Render often find this is one of the more immediately noticeable improvements, separate from anything to do with Auth or Storage. How complex is a Render to Supabase migration, really? Component Complexity Why Database (schema + data) Low Both platforms are standard Postgres; official path is pg_dump/psql, same as a Heroku migration Authentication Low–Moderate Render never bundled Auth; often a green-field adoption or a deliberate integration decision, not a forced migration Storage Low Rarely bundled with Render already; consolidating into Supabase Storage is optional Connection pooling N/A — net improvement Not available on Render Postgres at any tier; included by default on Supabase Overall: low, in the same category as a Heroku migration and for the same underlying reason — both source platforms are standard Postgres, so there's no data model redesign to plan around. The main project work is deciding what to do about Auth, Storage, and Realtime, not moving the data itself. Common pitfalls we see Discovering a free-tier database already expired. Because Render's free Postgres deletes itself after 30 days with no grace period, teams sometimes plan a migration only to find the source data is already gone. If you're on the free tier and know a migration is coming, don't let the 30-day clock run out first. Assuming connection pooling behavior carries over identically. Since Render Postgres doesn't include pooling at any tier, application code sometimes has workarounds (aggressive connection limits, manual pool management) that were compensating for its absence. Those workarounds are usually safe to remove once Supabase's built-in pooling is in place, but it's worth reviewing rather than assuming. Treating the database migration as the whole project. As with other database-only sources, the real scoping work is deciding what to do about Auth, Storage, and Realtime — not the pg_dump/psql step itself. Not checking for Render-specific environment configuration. Render's Blueprint specs and environment group setup don't have a direct Supabase equivalent and need to be accounted for separately in your deployment pipeline, even though they're unrelated to the database migration itself. A quick pre-migration checklist If you're on Render's free Postgres tier, how close are you to the 30-day expiration? Plan around this deadline explicitly — there's no recovery once it passes. Do you have workarounds in your application code for the lack of connection pooling? Worth identifying before migration so you know what can be simplified afterward. Do you have an existing Auth, Storage, or Realtime solution, or is this a green-field decision? This determines whether Auth is a migration or a fresh adoption. Are you using Render-specific features (Blueprint specs, environment groups, cron jobs) that need a separate migration plan outside the database itself? What's your tolerance for downtime during cutover, and does your current setup support a staged migration versus a single maintenance window? 🔄 Ready to consolidate off a database-only platform? Gart Solutions runs Render to Supabase migrations end to end — including the Auth, Storage, and connection pooling decisions that come with adopting a full platform. See how our migration practice works → How Gart Solutions approaches these migrations A Render to Supabase migration follows the same low-risk shape as a Heroku migration on the database side, with its own specific details worth getting right. Our process typically covers: Database migration — pg_dump/psql, validated against schema and row counts, with particular attention to free-tier expiration timing where relevant Auth and platform strategy — a deliberate recommendation on Supabase Auth, Storage, and Realtime adoption based on what's already in place Connection pooling review — identifying and safely removing any application-level workarounds that were compensating for Render's lack of built-in pooling Environment and deployment migration — accounting for Render-specific configuration (Blueprints, environment groups, cron jobs) that sits outside the database itself Just as important: we handle migrations of any level of complexity, not only from Render. The same team that runs a fast, low-risk Render migration also handles migrations from Firebase, Amazon RDS, Neon, Heroku, and legacy MySQL or MSSQL databases onto Supabase — and, where it's the right call for a client, migrations away from Supabase too. Whatever the source, the underlying discipline is the same: a validated plan and no surprises in production. Conclusion Render remains a solid choice for teams that specifically want straightforward, Git-based deployment and are comfortable sourcing Auth, Storage, and Realtime separately — or don't need them yet. But for teams that have hit Render Postgres's specific limitations — a hard 30-day expiration on the free tier, no connection pooling at any level, expensive high availability — or simply want one platform instead of several, a Render to Supabase migration is about as low-risk as this series gets. The database move itself is a well-tooled Postgres-to-Postgres migration; the real decision is what the rest of your platform should look like once you're not assembling it piece by piece. Planning a Supabase or Postgres migration? Gart Solutions' database migration engineers plan and execute Postgres migrations — into Supabase, within a live schema, or off a managed platform entirely — with a rollback plan built in from day one, not bolted on after something breaks. 40% cost reduction on a comparable Postgres migration 25% query performance improvement Minimal downtime during cutover Database Migration Cloud Migration SRE & Monitoring Compliance Audit Talk to a migration engineer  →