Vercel, Neon, Railway, Supabase, Cloudflare, Render, Fly.io, Convex, Upstash, Sentry, Clerk, Trigger.dev, OpenAI, Groq, and the complete modern developer stack

Updated: October 1, 2026.

The names in the tables link to official product pages. The brief assessments are editorial summaries of each product's purpose and trade-offs, not independent benchmark tests. Prices and free-plan limits are omitted because they change; check current terms and regional availability before choosing a service.

If you are building a web app, SaaS product, API, AI product, or mobile backend today, you almost certainly do not need to maintain every part of the infrastructure yourself.

Hosting, databases, authentication, storage, video, background jobs, observability, email, feature flags, AI inference, and even complete backend systems are available as managed services.

There are so many options that answering one question has become difficult:

“What do I actually need?”

Vercel, Neon, and Railway, for example, often end up on the same list of “cloud platforms,” even though they do different things.

• Vercel is primarily a platform for deploying and running web applications.
• Neon is a serverless PostgreSQL platform.
• Railway is a more general PaaS for applications, containers, databases, and supporting services.

They should not be chosen as if they were interchangeable.

Today's stack is usually assembled from several specialized layers.

This guide covers 150 currently relevant services and platforms, from small developer projects to serious production infrastructure.

Prices are intentionally not listed in detail because free tiers, limits, and usage billing change much faster than the core purpose of a product.

---

1. Hosting, deployment, and PaaS

Today's market is broadly divided into frontend-first platforms such as Vercel and Netlify, full-stack PaaS platforms such as Railway and Render, and more infrastructure-oriented platforms such as Fly.io.

---

2. More deployment and infrastructure platforms

What would I choose?

For Next.js, I would look at Vercel first.

For a conventional full-stack app, Railway or Render.

For Docker serverless workloads, Google Cloud Run.

For globally distributed services, Fly.io or Cloudflare.

For your own VPS, Coolify or Dokploy.

---

3. Serverless and managed databases

Serverless databases have become one of the most important parts of a modern stack. Neon and PlanetScale are primarily database services, while Supabase, Firebase, Appwrite, and Convex provide a much larger part of the backend.

---

4. Caching, analytics, and specialized databases

---

5. Object storage, images, and video

Storage pricing is not the only number that matters. With large amounts of content, outbound bandwidth costs, also known as egress, can become much higher than the storage bill itself. Cloudflare R2 does not charge direct internet egress fees. Storage and operations are still billed, and related services may have separate charges. Check the official R2 pricing page before estimating the total cost.

---

6. Authentication and identity

Modern auth services are no longer just “login APIs.” MFA, passkeys, OAuth, SSO, organizations, RBAC, provisioning, and enterprise identity are all part of the same category today.

---

7. Background jobs, queues, and durable workflows

This is one of the areas that has changed the most. A simple queue is not the same as a durable workflow. A queue is enough for “send an email later”; a process that “calls AI, waits for a webhook, charges the user, then sends the result” is a much better fit for a durable workflow engine.

---

8. Observability, errors, logs, and uptime

Modern observability increasingly relies on shared telemetry standards instead of fully proprietary agents. OpenTelemetry covers logs, metrics, and traces, and continues to expand toward profiling in 2026.

---

9. CI/CD and build infrastructure

For GitHub projects, there is little reason to introduce a separate CI service until GitHub Actions becomes a real limitation. Comparisons from 2026 still show that the location of the repository is one of the most important criteria when choosing a CI system.

---

10. Headless CMS and content platforms

The headless CMS market is already mature. Sanity, Contentful, Storyblok, Strapi, Payload, Directus, Prismic, and Hygraph solve a similar basic problem, but differ greatly in editor experience, self-hosting, and content modeling.

---

11. Search and vector databases

Traditional full-text search and AI vector search are not the same thing. Algolia and Typesense excel at application search, while Pinecone, Weaviate, Qdrant, and Zilliz target embedding and semantic-search workloads.

---

12. AI models, inference, and GPU APIs

AI infrastructure is no longer limited to calling one company directly. There is now a whole layer of inference providers that offer access to many open and proprietary models. Hugging Face, for example, integrates multiple inference providers into the same ecosystem.

---

13. Email, messaging, and notifications

Transactional email and marketing email should not automatically be treated as the same thing. A password reset and a store receipt have different priorities from a newsletter campaign.

---

14. Product analytics, experimentation, and feature flags

Product analytics is not the same as traditional web analytics. Amplitude, Mixpanel, and PostHog try to answer what users do inside a product and why certain features improve retention or conversion.

The feature flag market is increasingly split between managed SaaS, open-source and self-hosted tools, and all-in-one platforms such as PostHog.

---

15. Secrets, credentials, and application security

An .env file is no longer a serious credential-management strategy when an application has dozens of services, CI/CD pipelines, multiple environments, and AI agents.

In 2026, there is particular focus on non-human identities, short-lived credentials, and preventing API keys from leaking through code, build logs, and agent workflows.

---

How I would assemble a stack today

The biggest mistake is trying to find one service that does everything.

It is much healthier to think in layers.

A small Next.js SaaS

Vercel + Neon + Clerk + Cloudflare R2 + Resend + Sentry + PostHog

That is an exceptionally productive stack for a solo developer or a small team.

A full-stack application with a more substantial backend

Railway or Render + PostgreSQL/Neon + Redis + Cloudflare R2 + Better Stack/Sentry

There are fewer serverless constraints, and deploying workers and background processes is straightforward.

A realtime application

Vercel + Convex

or

Supabase + your own frontend

Here, a single BaaS can remove a huge amount of backend infrastructure.

An AI SaaS

Vercel/Cloud Run + Neon + R2 + OpenAI/Anthropic + Groq/Together/Fireworks + Trigger.dev/Inngest + Axiom/Sentry

It is especially important to separate synchronous user requests from long-running AI tasks.

A global edge application

Cloudflare Workers + R2 + Queues + D1/KV/Durable Objects

or

Fly.io + a distributed database

A privacy-focused and open-source stack

Coolify + PostgreSQL + MinIO/S3-compatible storage + Infisical + SigNoz + Plausible + GrowthBook

This gives you much more control over your data and infrastructure.

---

The most important practices for 2026

Do not choose a service based only on its free tier

A free tier is great for development.

It is not an architecture.

Check what happens when a project reaches:

• 100,000 users
• millions of database operations
• tens of terabytes of bandwidth
• large volumes of logs
• background workloads
• multiple developers
• multiple regions.

---

Watch out for egress

Storage that costs a few dollars a month can generate hundreds of dollars in bandwidth charges.

That is exactly why services such as R2 and B2 can be very interesting for media-heavy applications.

---

Keep your application and database geographically close

The frontend can be cached globally.

Database round trips cannot magically disappear.

If your API runs in Frankfurt and your database is in California, every request pays a latency penalty.

---

SQL compatibility has value

PostgreSQL and MySQL-compatible services generally make future migrations easier.

Fully proprietary data models can provide a fantastic developer experience, but they increase the cost of eventually leaving the platform.

---

Use standards where possible

OpenTelemetry is especially useful for observability.

For feature flags, vendor-neutral abstractions such as OpenFeature are increasingly useful.

For object storage, S3 compatibility is a major advantage.

A standard interface does not eliminate vendor lock-in, but it can reduce it significantly.

---

A background task is not an HTTP request

Generating a PDF, running two minutes of AI inference, processing video, or sending thousands of emails should not block a user-facing HTTP request.

That is what these are for:

• queues
• workers
• scheduled jobs
• durable workflows.

---

Use a durable workflow when a job has state

If a process needs to:

1. perform an operation,
2. wait for an hour,
3. receive a webhook,
4. retry a failed step,
5. resume where it stopped,

a regular cron job or queue is often no longer enough.

Temporal, Inngest, Trigger.dev, Upstash Workflow, and similar systems exist for exactly this reason.

---

Keep secrets out of Git

API keys, database credentials, and production tokens should be managed by a secrets system.

This is even more important with AI coding agents, which now have access to repositories, terminals, MCP services, and deployment environments.

---

One important change in the Vercel ecosystem

Older tutorials often mention Vercel Postgres as a standalone Vercel product.

That is no longer the current architecture.

Vercel Postgres is no longer available as a standalone product. Existing databases automatically migrated to Neon in December 2024, and new databases are added through Marketplace integrations. For example, a Vercel application can use Neon or Supabase for PostgreSQL and Upstash for Redis.

So a stack like this is completely normal today:

Vercel for the application + Neon for PostgreSQL + Upstash for Redis.

You do not need to buy everything from the same provider.

---

My practical method for choosing services

Before adding a new service, ask seven questions:

1. What specific problem does it solve?
2. Can something we already use solve the same problem?
3. How much vendor lock-in does it create?
4. What does pricing look like when traffic grows 10×?
5. Where is the data physically stored?
6. How can we export the data if we decide to leave?
7. What happens when the service goes down?

If you cannot answer these questions clearly, it is too early to make the service a critical part of your infrastructure.

---

What I would avoid

I would not build an application with:

Vercel for the frontend, Render for one API, Railway for another API, Supabase just for auth, Neon for the database, Firebase for one realtime feature, three different storage services, and four analytics SDKs.

Technically, it is possible.

Operationally, it becomes a mess.

Every new provider brings:

• a new bill
• a new dashboard
• a new API key
• a new failure mode
• new documentation
• a new security boundary
• new vendor lock-in.

Managed services should reduce complexity, not move it from your servers to 25 dashboards.

---

Conclusion

In 2026, finding a service that can do something is not the problem.

The challenge is choosing the smallest number of services that together form a healthy architecture.

Most modern projects do not need their own Kubernetes cluster, five virtual servers, and an infrastructure administrator.

You can start with something like:

Vercel + Neon + Cloudflare R2 + Clerk + Resend + Sentry

and already have a very serious foundation.

If the backend needs more, add Railway, Render, or Cloud Run.

If background jobs appear, add Trigger.dev, Inngest, or a queue.

If your telemetry grows, move to a more capable observability system.

Only consider a more complex cloud setup and Kubernetes if your infrastructure outgrows a managed PaaS.

The best cloud stack is not the one that uses the most modern services.

It is the one that keeps your product simple for as long as simplicity is enough.