# When to Avoid Using Serverless Functions

- Date: 2025-09-05T20:54:00.000Z
- Tags: Cloud
- URL: https://render.com/articles/when-to-avoid-using-serverless-functions

Serverless functions (such as those powered by AWS Lambda) are popular for good reason: teams can run code without managing servers, scale automatically with demand, and pay only for actual execution time. For sporadic, event-driven tasks, the serverless model often reduces overhead and speeds up delivery.

Common fits for a serverless function include:

- *Simple image processing* like thumbnail generation triggered by uploads.
- *Webhooks* that process occasional events from third-party APIs.
- *Data pipelines* that involve small, on-demand ETL steps.

These use cases share a bursty, self-contained profile that lends itself to per-request execution. But not every application matches that profile. For services that require low latency, long-lived connections, or sustained throughput, serverless can fall short compared to an "always-on" model. This article unpacks when functions might become a liability, and what you can use instead.

## Checklist: Is serverless right for you?

If you're considering serverless for your project, first ask yourself these questions:

- *Does your application have strict latency targets or real-time user interactions?* AWS notes that cold starts add latency, especially after idle periods<sup>[1](https://aws.amazon.com/blogs/compute/operating-lambda-performance-optimization-part-1/)</sup>.

- *Does your process run longer than 15 minutes?* Lambda (like most other serverless providers) imposes a hard execution limit that terminates long-running processes<sup>[2](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)</sup>.

- *Does your application need persistent connections or high database concurrency?* This includes WebSockets, [AI agent streams](https://engineersguide.substack.com/p/best-infrastructure-for-streaming), database pools, or connection reuse requirements. RDS Proxy can help on the database side, but it adds complexity<sup>[3](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy-network-prereqs.html)</sup>.

- *Does your application have sustained, predictable traffic patterns?* Consistent load derives less benefit from "bursty" serverless scaling.

- *Does your application require advanced debugging capabilities?* This might include custom agents, deep logging support, or local development environment parity.

- *Does your application need predictable costs?* Steady, provisioned spending introduces fewer surprises than variable per-request billing<sup>[4](https://aws.amazon.com/lambda/pricing/#AWS_Lambda_Pricing)</sup>.

If you answered "yes" to more than two of the above, serverless probably _isn't_ the right tool for your use case. Otherwise, serverless is probably a solid fit.

## When to avoid serverless functions

### Latency-sensitive APIs

For login endpoints, checkout flows, or any user-facing API requiring sub-200 ms response times, cold starts can meaningfully degrade the user experience. Provisioned concurrency can help here, but it adds cost and management overhead<sup>[5](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html#configuring-provisioned-concurrency)</sup>.

### Long-running or streaming jobs

Any task that might hit Lambda’s 15-minute cap<sup>[2](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)</sup> (like report generation, video processing, or the data ingestion pipelines common to [production AI applications](https://render.com/articles/scaling-ai-applications-prototype-to-millions)) is better suited to an always-running worker. This stability is particularly critical for [full-stack GenAI](https://render.com/articles/serverless-vs-unified-genai-backends) workloads, where strict timeouts disrupt RAG pipelines and long inference.

### Persistent connections and real-time protocols

Functions don’t hold connections well. Services using WebSockets, gRPC streams, or large RDBMS pools risk hitting connection exhaustion without an intermediary like RDS Proxy.

### High, steady throughput

When services run at scale for hours daily, per-request billing becomes less efficient. Provisioned capacity often yields lower unit cost.

### Complex debugging and observability

Functions limit access to logs, custom monitoring agents, or deep introspection. Tracing across services often requires additional tools and wiring.

### Heavy runtimes and dependencies

Large libraries or container images inflate startup times, compounding cold start delays and making performance less predictable.

## Two concrete examples

### Checkout API under 150 ms

An e-commerce team targets P99 latency below 150 ms. Using functions, cold starts and concurrency spikes jeopardize SLAs. Provisioned concurrency helps but increases costs. On Render, a [web service](https://render.com/docs/web-services) runs continuously, eliminating cold starts while autoscaling with demand.

### Nightly data compaction job

A data team needs a batch job to run 45–60 minutes nightly. Lambda’s hard timeout blocks this outright<sup>[2](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)</sup>. On Render, a [background worker](https://render.com/docs/background-workers) handles the task, with logs for retries and scaling controls for resource efficiency.

## The Render path for always-running applications

Render offers a straightforward model for applications that don’t conform nicely to the serverless model:

- *Architecture:* Run APIs as [web services](https://render.com/docs/web-services), schedule [cron jobs](https://render.com/docs/cronjobs), and keep internal communication private with [private networking](https://render.com/docs/private-network).

- *Operations:* [Zero-downtime deploys](https://render.com/docs/deploys#zero-downtime-deploys) keep services online, while built-in [logs](https://render.com/docs/logging) and [metrics](https://render.com/docs/service-metrics) simplify debugging.

- *Scaling:* Configure autoscaling in the dashboard or `render.yaml`, targeting CPU and/or memory thresholds.

- *Cost planning:* Transparent, provisioned [pricing](https://render.com/pricing) makes monthly budgets predictable.

Render's service-based architecture covers latency-sensitive APIs, long-running jobs, and stateful applications, while avoiding the limits and operational friction common in function-based models.

## Finding the right balance

Serverless remains an excellent choice for bursty, event-driven workloads with minimal state. And in fact, many teams thrive with a hybrid model: functions at the edges for glue code or sporadic triggers, accompanied by always-on services at the core for stateful, long-lived, or latency-critical tasks. Render complements rather than replaces serverless, giving teams a smooth path for scenarios where functions fall short.

## Test your use case with Render

Start small: [deploy](https://render.com/docs/your-first-deploy) a simple always-running API on Render, enable [autoscaling](https://render.com/docs/scaling#autoscaling), and connect services over your [private network](https://render.com/docs/private-network).

Compare latency and cost variability against an equivalent serverless design. The right compute model depends on your use case, but Render makes the always-on path easy.