[{"data":1,"prerenderedAt":16},["ShallowReactive",2],{"$fPgoXeDM9FtObsw0cYQlZoXGe7dyn2XSPW-uzOSjPTOg":3},{"slug":4,"title":5,"description":6,"date":7,"tags":8,"draft":13,"readingMinutes":14,"html":15},"neon-vs-supabase","Neon vs Supabase: Which Postgres Should You Pick?","Neon vs Supabase in October 2026: same Postgres, different bills. Scale-to-zero vs a flat $25, branches vs projects, and which one fits which app.","2026-10-15",[9,10,11,12],"neon","supabase","postgres","backend",false,5,"\u003Cp>Neon vs Supabase used to be an easy call. Neon was a database. Supabase was a database plus auth, storage, functions and a dashboard your non-technical cofounder could click around in. If you wanted "the whole backend", you picked Supabase, and if you wanted "just Postgres, cheap and serverless", you picked Neon.\u003C/p>\n\u003Cp>That line is gone. Neon, now part of Databricks, sells itself as "a complete set of cloud backend primitives" and lists Managed Better Auth, a Data API, Functions, Object Storage and an AI Gateway next to the database. Both are Postgres underneath, both speak plain SQL, and both will run a normal Node, Laravel or Next.js app without complaint. So the real difference now is how each one charges you and how each one treats an idle database. That's what this comparison is about.\u003C/p>\n\u003Cp>Prices below are from \u003Ca href=\"https://neon.com/pricing\">neon.com/pricing\u003C/a> and \u003Ca href=\"https://supabase.com/pricing\">supabase.com/pricing\u003C/a>, checked on October 15, 2026.\u003C/p>\n\u003Ch2>The billing model is the whole argument\u003C/h2>\n\u003Cp>\u003Cstrong>Supabase Pro\u003C/strong> is $25 a month for the first project, and that includes $10 of compute credit, which covers one Micro instance (1 GB of RAM). It also includes 8 GB of disk, 100,000 monthly active users, 250 GB of egress and 100 GB of file storage. The server runs all month whether anyone uses it or not. A paid project never pauses.\u003C/p>\n\u003Cp>\u003Cstrong>Neon Launch\u003C/strong> has no monthly fee at all. You pay $0.106 per compute-unit hour, where one compute unit is about 4 GB of RAM, plus $0.35 per GB-month of storage. The important part: after 5 minutes without queries, the compute suspends, and suspended compute costs nothing. The next query wakes it up, which Neon says takes "a few hundred milliseconds".\u003C/p>\n\u003Cp>Here's what that means for a real-shaped app. Say a small B2B tool where people work US office hours, so the database is busy about 10 hours a day and idle the rest. Give it 0.25 CU, roughly the same 1 GB of RAM as Supabase Micro, and 5 GB of data.\u003C/p>\n\u003Cimg src=\"/blog/neon-vs-supabase/neon-vs-supabase-24-hours.webp\" alt=\"One weekday of a 1 GB Postgres database: Neon's compute runs only during 10 busy hours and costs nothing overnight, Supabase's runs all 24 hours\" width=\"1600\" height=\"900\" loading=\"lazy\">\u003Cp>On Neon that's 0.25 × 10 hours × 30 days = 75 CU-hours, which is $7.95, plus $1.75 for storage, so about $10 a month before the restore history (more on that below). Leave it running 24/7 and it's 182.5 CU-hours, about $19, still under Supabase's sticker. On Supabase the same database is $25 flat, and the bundle around it is bigger.\u003C/p>\n\u003Cp>So Neon wins on raw database cost for anything with quiet hours, and the gap gets wider the quieter the app is. An internal tool used twice a week costs almost nothing on Neon and still costs $25 on Supabase.\u003C/p>\n\u003Ch2>Where the cheap option gets expensive\u003C/h2>\n\u003Cp>I'd still not pick on that number alone, because the edges bite differently.\u003C/p>\n\u003Cp>On Neon, the cost follows the traffic. A cron job that pings the database every 4 minutes means it never sleeps, and you've just paid for 730 hours instead of 300. Background workers, health checks from an uptime monitor pointed at an endpoint that queries the database, an ORM that keeps a connection open: any of these quietly kill scale-to-zero. Autoscaling is the other one. Launch can scale a compute up to 16 CU, which is lovely during a spike and less lovely on the invoice. Cap the autoscaling range per compute. Neon's own cost guide says the same.\u003C/p>\n\u003Cp>Neon also bills the restore history: $0.20 per GB-month for the instant-restore window on the root branch (up to 7 days on Launch). Shorten the window if you don't need a week of point-in-time restore on a side project.\u003C/p>\n\u003Cp>On Supabase the trap is the other way around: things that never turn off. The compute credit covers one Micro instance per organization, not per project. A staging project is another Micro, about $10 a month, every month, and Supabase's branching is billed at $0.01344 per branch per hour, which is the same Micro price again if the branch stays up. I wrote up the rest of Supabase's bill in \u003Ca href=\"/blog/supabase-pricing\">Supabase pricing: what drives the bill\u003C/a>, including the disk that grows and never shrinks.\u003C/p>\n\u003Ch2>Branches vs projects\u003C/h2>\n\u003Cp>This is the part that changes how you work day to day, not just what you pay.\u003C/p>\n\u003Cp>A Neon branch is a copy-on-write clone of your database. Making one is instant, it starts at $0 of storage, and you get 10 per project on Free and Launch before the $1.50 per branch-month charge starts. People use them for a branch per pull request, or a disposable copy of production to test a migration against real data. When the branch's compute is idle, it scales to zero like everything else.\u003C/p>\n\u003Cp>Supabase can do branching too, on paid plans, and it's integrated with its GitHub flow, but each branch is a running instance with an hourly price. It's fine. It's just not something you hand out casually.\u003C/p>\n\u003Cp>If your team does migrations against a copy of real data before every release (and you should), Neon's model is nicer to live with.\u003C/p>\n\u003Ch2>When I'd pick Supabase\u003C/h2>\n\u003Cul>\n\u003Cli>The app needs auth, file uploads, realtime and row-level security, and you want them working this week. Supabase's auth, storage and realtime have been in production for years, the dashboard is good, and the docs answer most questions. Neon's auth and storage are newer.\u003C/li>\n\u003Cli>Someone non-technical needs to look at the data. Supabase's table editor is a real tool.\u003C/li>\n\u003Cli>The app is busy all day anyway. If the database never sleeps, scale-to-zero saves nothing, and the $25 bundle is good value.\u003C/li>\n\u003Cli>The frontend came out of an AI builder that already speaks Supabase. Swapping the backend costs more than it saves.\u003C/li>\n\u003C/ul>\n\u003Ch2>When I'd pick Neon\u003C/h2>\n\u003Cul>\n\u003Cli>The backend is your own code (Laravel, Express, Next.js API routes) and you only want Postgres. You don't need the rest of the bundle.\u003C/li>\n\u003Cli>Many small databases: per-customer databases, preview environments, side projects, internal tools. A hundred mostly idle databases are cheap on Neon and expensive on anything that bills per running server.\u003C/li>\n\u003Cli>You want a database per pull request.\u003C/li>\n\u003Cli>Traffic is spiky or office-hours only.\u003C/li>\n\u003C/ul>\n\u003Cp>There's no wrong answer between the two for a typical CRUD app. Both are Postgres, so moving later is a \u003Ccode>pg_dump\u003C/code> and a connection string change, plus whatever you built on the platform-specific extras (Supabase Auth or Neon's Data API). Keep those extras behind your own code and the choice stays cheap to undo.\u003C/p>\n\u003Cp>If you're starting something and want a second opinion on the stack, or you already have an app and the database bill doesn't look right, \u003Ca href=\"https://calendly.com/director-norsky/meeting\">book a free call\u003C/a>. Database bills are also one of the things I cut under my \u003Ca href=\"https://slashcloudbill.com/\">pay-from-savings cloud cost offer\u003C/a>.\u003C/p>\n",1792024222375]