Supabase is the cornerstone of many low-code and no-code platforms (Lovable would be a good example of that) and has gained a lot of traction since the advent of the vibe-coding age. And for a reason — it is very easy and straightforward to use for AI coding agents and humans alike.
The idea behind it is very simple: Postgres (open source) + PostgREST (also open source) + Auth (GoTrue — you guessed it — open source) + Edge Functions API (Deno, open source) + Storage API for binary storage.
In short, it is BaaS, or backend as a service, or, in other words, you want to have a backend but do not want to manage it in any shape or form — Supabase is here. It handles deployment, scaling, authentication, and database management for you, so you can work on your product.
In a sense, it removes the need to have a dedicated devops/admin/database admin. For a startup, the benefits are obvious: there is rarely an abundance of available free time or hands, so a lot of time can be saved by offloading backend management. And, let’s be honest, who wants to do that stuff anyway? Certainly, you would rather spend that time more productively, for example by doom-scrolling on Twitter.
It is open source, which removes the notorious vendor lock-in problem that exists with similar older solutions like Firebase. Since it is just Postgres with a bunch of open-source bells and whistles, you can always migrate away from Supabase or deploy your own.
So the benefits for a startup or a small POC project are evident. But what about larger, enterprise-scale projects? Can Supabase handle those?
The answer is — probably not.
It is not Supabase’s fault, though — it is intentional design. As you can see, the central part of Supabase is Postgres, so if you don’t want to use Postgres — and many enterprise solutions wouldn’t — you are out. But even if that was not a problem, the core idea of Supabase is built around a backend based on managing relational data with lots of simple CRUD operations and (ideally) row-level security (or simply, security based on data access rules) rather than a complex role-based system.
How many enterprise systems fit that description? I think not many. If your system has complex logic and lots of integrations with external systems, you will need advanced architecture patterns like microservices, event sourcing, custom queues/streams, long-running jobs, etc. Supabase is not going to make this easier for you here — probably more difficult, because it wasn’t built for that. Technically, you can separate all of that into separate service(s) and use Supabase for basic logic — but what’s the point of that, as in this case this is not what would constitute the bulk of project effort anyway.
Otherwise, Supabase is a wonderful instrument for its purpose. Open source, flexible enough to get many startup ideas a very long way before it exceeds its capacity.
Vercel
Now let’s look at Vercel. Vercel is a FaaS, or frontend as a service (although now they have some backend features as well). As you can see from the name, it serves the other side of the equation, so it can be used together with Supabase, which is quite common.
Vercel is a cloud platform that is focused on frontend, specifically instant easy deployment, CI/CD, CDN, and very fast delivery and scaling with (almost) zero maintenance, serverless functions that are specially optimized for Next.js.
In fact, Next.js was created by Vercel, so as you can imagine, their platform is highly optimized for its use, although you can use most popular JS frameworks if you want. The platform automatically detects the framework being used and sets up the correct build and output settings.
Vercel is not open source, although many of its components like Next.js are. So it’s not like Supabase, and the problem of vendor lock-in does exist and has to be considered if you want to use it. A lot of Vercel features will be difficult to migrate away from if used; for example, Edge Functions / Middleware are run on a proprietary, non-standard Edge Runtime.
Vercel is quite similar to Supabase, albeit more limited. It is very good for startups and Node.js projects of medium complexity that require very high frontend performance. It’s not going to work well with non-Node.js backends, and it is not built for real-time (i.e. WebSockets) apps because it doesn’t support long-running processes. So the whole point of it is speed of development and speed of the frontend app. Vercel is not suitable for complex web applications with lots of integrations where you need to fine-tune your backend extensively. And it is not particularly cheap to use either once you have a lot of traffic.
So, if you are a startup that has raised a lot of cash and it burns your hands (while your investors are burning your ass) — using both Vercel and Supabase makes lots of sense. Neither replaces good system design, though.
Railway
Railway is a PaaS (platform as a service) — meaning it gives you infrastructure/runtime to run your backend but not the backend itself (like Supabase). It is not a black box, and it sits nicely between platforms like Vercel, giving you full control over backend architecture. If you used Heroku — it’s kind of like that but more modern.
The main idea is that you push code to the repo and Railway handles all the rest, and you get a production-ready service. It allows you to use dockerfiles if you want full control; otherwise, it will detect your stack automatically.
Unlike Vercel, it allows for long-running processes (although you will have to pay for that) and background workers. Essentially, it is a simpler alternative to managed Kubernetes, so you can concentrate on development instead of infrastructure/devops, but still have the flexibility of configuring everything yourself if you are up to that.
So essentially, you can use Railway up to the point when you need to switch to Kubernetes — a stage most projects never reach anyway.
The pricing is much more predictable compared to services like Vercel. Basically, you pay for usage, and it is reasonable. Of course, using something like Hetzner and managing infra yourself is cheaper in terms of money, but if you factor in the time to do that, things might start to look different — so you have to do your own math.
