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 periods1.
-
Does your process run longer than 15 minutes? Lambda (like most other serverless providers) imposes a hard execution limit that terminates long-running processes2.
-
Does your application need persistent connections or high database concurrency? This includes WebSockets, database pools, or connection reuse requirements. RDS Proxy can help on the database side, but it adds complexity3.
-
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 billing4.
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 overhead5.
Long-running or streaming jobs
Any task that might hit Lambda’s 15-minute cap2 (such as report generation, video processing, or continuous data streaming) is better suited to an always-running worker.
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 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 outright2. On Render, a background worker 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, schedule cron jobs, and keep internal communication private with private networking.
-
Operations: Zero-downtime deploys keep services online, while built-in logs and metrics simplify debugging.
-
Scaling: Configure autoscaling in the dashboard or
render.yaml, targeting CPU and/or memory thresholds. -
Cost planning: Transparent, provisioned 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 a simple always-running API on Render, enable autoscaling, and connect services over your 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.