For one or two long-running products that need tightly integrated Auth, RLS, Realtime, and Storage, Supabase is usually the simpler choice.
For several side projects that mainly need Postgres and can tolerate a modular setup, Vercel + Neon + Cloudinary + Auth.js can provide more flexibility and lower fixed cost per project.
The most useful lesson was that a free tier may be constrained by something other than traffic. Project count, storage model, media bandwidth, or a specific paid feature can become the real limit much earlier.
I originally evaluated these services for dreamlydia, my personal portfolio site.
At the time, I already had two long-running products on Supabase. Their actual usage was still modest, but those two projects had already consumed the Free plan's active-project allowance.
A third project would therefore create a cost decision because of project count, not because the new product had reached meaningful scale.
That changed the question from "Is Supabase or Neon better?" to a more practical set of constraints:
Supabase packages Postgres, Auth, Storage, Realtime, Edge Functions, and Row Level Security into one platform.
At the time of this comparison:
Its main advantage is the integration between services. Auth and RLS work naturally together, and Realtime is available without introducing another provider.
The limitation that mattered most in my case was not database capacity but the two-project Free-tier limit. For someone maintaining several small products, that can become a cost boundary before any individual project reaches significant usage.
Supabase is a strong fit when:
Neon is primarily a serverless Postgres service rather than an all-in-one backend platform.
At the time of this comparison, the Free plan allowed up to 100 projects per organization, with 100 CU-hours per project, 0.5GB storage, and 5GB egress. Paid plans were usage-based rather than primarily defined by a fixed monthly floor.
For multiple low-traffic side projects, that project-count difference is significant.
Neon also provides:
The trade-off is that Auth, media storage, and Realtime are not bundled. In my setup, Auth moved to Auth.js and media to Cloudinary.
That creates more integration work, but it also means each layer can be selected independently.
Neon fits well when:
Cloudinary handles image and video upload, transformation, optimization, and CDN delivery.
At the time of this comparison, the Free plan included 25 monthly credits. One credit could correspond to roughly 1,000 transformations, 1GB storage, or 1GB video bandwidth, depending on usage.
For a portfolio with many images and short videos, this removed the need to build a custom media-processing pipeline.
Useful capabilities included:
The main caveat is video. Storage, transformation, and bandwidth can consume credits much faster than normal image usage.
Vercel remained the deployment layer because the main requirement was a low-friction workflow:
At the time of this comparison, the Hobby plan was free for personal and non-commercial use and included generous request, bandwidth, and function allowances. Pro started at $20/month.
For small personal products, the free tier was enough. The point to reassess would be commercialization, team collaboration, or a meaningful increase in function and bandwidth usage.
Once the database moved away from Supabase, authentication also needed its own solution.
Auth.js worked for this project because the authentication requirements were relatively simple. I did not need the deeper Auth + RLS + Realtime integration that makes Supabase attractive in other products.
The decision principle is important: do not separate services just because modular architecture looks cleaner. Separate them only when the product does not benefit enough from tight platform integration to justify the coupling.
| Stack | Best fit | Main trade-off |
|---|---|---|
| Vercel + Supabase | 1–2 long-running products with Auth / RLS / Realtime needs | Lower integration effort, but project-count limits can become a cost boundary earlier |
| Vercel + Neon + Cloudinary + Auth.js | Several Postgres-based side projects with significant media needs | More integration work, but more independent services and a lower fixed cost across projects |
I currently use both patterns rather than forcing every project onto one stack. Existing long-running products remain on Supabase, while dreamlydia uses the modular stack.
Supabase: Project count can matter before traffic. I originally assumed that outgrowing a free tier would mean the product had become large. In practice, a third project triggered the decision before traffic became meaningful.
Neon: Compare the whole backend, not just the database line item. Moving from Supabase to Neon means replacing services that Supabase had bundled. Database pricing alone is not a fair system-level comparison.
Cloudinary: Free video is not costless video. Video consumes storage, transformation, and bandwidth simultaneously. A portfolio with many autoplay clips should monitor credits separately from image usage.
Modular stacks have an integration cost. Neon + Auth.js + Cloudinary is attractive in direct service cost, but it creates more environment variables, integration points, and failure modes than a single BaaS. For a tiny one-off project, the money saved may not justify the extra maintenance.
I no longer ask whether Supabase or Neon is universally better.
The more useful questions are: What capabilities does this project actually need? Which of them benefit from being tightly integrated? How many projects will I maintain? Which pricing dimension am I most likely to hit first?
For personal development, a cost-efficient stack is not simply the cheapest collection of services. It is the point where cash cost, integration complexity, maintenance time, and expected growth pattern are balanced for the project in front of you.