Supabase crossed a million databases created on its platform in 2024, most of them started by a developer who wanted a Postgres database and an API without standing up a server first. That pattern, reaching for a platform that hands you a working backend instead of assembling one from a cloud provider, is what the backend developer platform category is about. The tools differ sharply in how much of the backend they give you and how much you still write, so picking one comes down to matching the platform to the shape of the app you are building.

This roundup stays on platforms for building and running a backend, not the broader cloud development platforms that also cover frontend and edge, and not the platform engineering tools that sit on top of infrastructure as internal portals. The platforms here overlap on the same job, which is getting your services, data, and APIs into production, and they split into three groups by how they approach it.

Backend developer platforms fall into three groups: backend-as-a-service that generates an API from your database, a PaaS that runs your container, and code-first platforms that build the backend from your application code.

Your backendbuild and run

the choice

How much does the platform build for you?

three approaches

data-first

Backend-as-a-service

run-first

PaaS

code-first

Code-first platform

The platforms at a glance

Platform	Approach	Runs where	You write	Best fit
Supabase	Backend-as-a-service	Supabase cloud or self-host	SQL, edge functions	Data-centric apps, fast auth + storage
Nhost	Backend-as-a-service	Nhost cloud or self-host	GraphQL, serverless functions	GraphQL-first apps on Postgres
Railway	PaaS	Railway cloud	Your services, any language	Ship an existing backend fast
Render	PaaS	Render cloud	Your services, any language	Web services with managed add-ons
Fly.io	PaaS	Fly global edge	Your container	Latency-sensitive, multi-region apps
Encore	Code-first platform	Your AWS or GCP	TypeScript or Go services	Distributed backends, infra ownership

Backend-as-a-service: Supabase and Nhost

Supabase and Nhost start from a database and build the rest of the backend around it. You define your tables, and the platform generates an API over them, adds authentication, file storage, and realtime updates, and gives you a place to run the small amount of custom logic that does not fit as a query.

Supabase generates both a REST and a GraphQL API from your Postgres schema, so a table becomes an endpoint the moment you create it, with row-level security policies enforcing who can read and write what. Auth, storage, and realtime subscriptions come built in, and edge functions handle logic that cannot live in the database. It is open source and can be self-hosted, which matters to teams that want to avoid a hard dependency on the hosted service. The fit is strongest when the database is the center of the app and the backend is mostly reads and writes with permission rules. As business logic grows past what row-level security and a scattering of edge functions can express cleanly, teams tend to feel the pull toward a service layer they write themselves.

Nhost takes the same backend-as-a-service shape but centers on GraphQL through Hasura, again over Postgres, with auth, storage, and serverless functions alongside it. If your frontend is already GraphQL-first, Nhost removes the work of building and maintaining the GraphQL server. The tradeoff is the same as Supabase's: the platform is excellent at the data-and-permissions layer and lighter once the app needs substantial custom services.

Platform-as-a-service: Railway, Render, and Fly

A PaaS does not care how you wrote your backend. You bring a repo or a container, and the platform builds it, deploys it, scales it, and gives you managed add-ons like Postgres and Redis so you are not running those yourself. This is the most direct path if you already have a backend, in any language, and want somewhere to run it without a cloud console.

Railway leans hard on developer experience. You connect a repo and get a deploy in minutes, with a clean interface for services, variables, and databases, and provisioning a Postgres instance is a couple of clicks. It suits teams that want to ship quickly and treat infrastructure as something they configure rather than something they build. Render covers similar ground with a focus on web services, cron jobs, and managed databases, with pricing and behavior that stay predictable as you add pieces. Fly.io is the one to reach for when latency to users matters, since it runs your containers across a global network of regions and makes multi-region deployment a first-class concern rather than an afterthought, at the cost of expecting you to be comfortable with Docker and to bring your own observability stack.

Across all three the model is the same: they run the backend you wrote and manage the machines under it, and they stop at the edge of your application code. The services, the calls between them, and the infrastructure your app declares are yours to design.

Code-first platforms: building the backend from application code

The third approach moves the platform into the code itself. Instead of generating a backend from a schema or running one you deployed, a code-first platform derives the running system from how the application is written, including the databases, queues, and cron jobs the app declares and the calls services make to each other. This is a narrower category, and Encore is the clearest example of it, so it also serves as the "where Encore fits" for this roundup.

Where Encore fits

Encore is an open-source backend framework, TypeScript on a Rust runtime or Go, paired with a platform. You declare infrastructure as typed objects in your application code, a Postgres database, a Pub/Sub topic with delivery guarantees, a cron job, an object storage bucket, and Encore provisions those resources into your own AWS or GCP account rather than onto its own infrastructure. Services call each other as type-checked function calls through generated clients, and distributed tracing is built in rather than bolted on.

import { api } from "encore.dev/api";
import { SQLDatabase } from "encore.dev/storage/sqldb";

// The database is declared in code and provisioned into your cloud account.
const db = new SQLDatabase("users", { migrations: "./migrations" });

export const getUser = api(
  { method: "GET", path: "/users/:id", expose: true },
  async ({ id }: { id: string }): Promise<User> => {
    const user = await db.queryRow`SELECT * FROM users WHERE id = ${id}`;
    if (!user) throw APIError.notFound("user not found");
    return user;
  },
);

Running encore run starts the app locally with a real database, tracing, and a development dashboard, and pushing to deploy provisions the cloud resources, wires up IAM and networking, and gives you preview environments per pull request, CI/CD, a service catalog, and an architecture diagram generated from the code. Because infrastructure is inferred from what you write, an AI agent working on the backend produces application code rather than Terraform, which is easier to review and harder to misconfigure. The output stays portable: encore build docker exports a standard image, resources live in your account from the start, and Encore integrates with existing Terraform through a provider that exposes provisioned resources as data sources.

Encore supports TypeScript and Go, so a Python or Ruby backend rules it out, and it expects you to write services Encore's way rather than deploying an arbitrary container the way a PaaS does. If your app is mostly database reads and writes with auth, a backend-as-a-service like Supabase will get you there with less code. Encore fits when you are building a backend of real services, want the databases and queues in your own cloud account, and want tracing and service boundaries without running the plumbing yourself. The internal developer platform and backend build-and-run guides go deeper on that model, and it sits in a different category from the Backstage-style portals that catalog services rather than build them.

How to choose

Pick by the shape of the backend, not by which platform does the most:

• If the app is data-centric, mostly reads and writes with permissions, and you want auth and storage handled, start with a backend-as-a-service like Supabase or Nhost.
• If you already have a backend, or want freedom in language and framework, and you just need somewhere to run it, a PaaS like Railway, Render, or Fly is the shortest path. Reach for Fly specifically when multi-region latency is a requirement.
• If you are building a backend of several services, want the infrastructure in your own AWS or GCP account, and want tracing and service boundaries without operating them, a code-first platform like Encore fits.

The groups are not mutually exclusive in practice. Plenty of teams run a Supabase database behind services they deploy on a PaaS, and the right answer is often a combination that matches how the app is built.

Related reading

• Best Cloud Development Platforms in 2026
• What Is an Internal Developer Platform?
• Platform as a Service Explained
• Internal Developer Platform vs PaaS
• How to Build an Internal Developer Platform
• Backend as a Service Explained
• Supabase Alternatives
• Encore quick start