#Using Convex as severless functions

15 messages · Page 1 of 1 (latest)

thorny girder
#

I have a use case where I want to use Convex's serverless functions fot Twilio webhooks and for it to run there.

I like how Convex's architecture but i'm wondering if this has the same scalability as like a lambda function or a cloudflare worker. I want to know if it autoscales and would be a lot quicker than for example a supabase database running prisma accelerate

latent stumpBOT
#

Hi @thorny girder. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

Short answer: Yes—Convex can handle Twilio webhooks and it auto‑scales function execution, but it’s not identical to Lambda/Workers.

  • Twilio webhooks: Use the Convex Twilio component, which registers HTTP handlers in your Convex deployment (e.g. /twilio/incoming-message) and lets you run your own logic in a callback within the same transaction as message insertion (Twilio component docs).
  • Autoscaling: Convex horizontally scaled its function runner (“Funrun”), allowing pro customers to run far more functions concurrently and for Convex to scale the function-running service independently as demand grows (How we horizontally scaled functions, Impact).
  • Performance model: Convex runs your functions on V8 isolates for low latency without container cold starts; this was a deliberate choice vs. traditional serverless like Lambda, which can have higher cold start overheads (Horizontally scaled functions).
  • Architecture fit: Queries/mutations are transactional (deterministic) and actions are for side effects/network I/O (ideal for handling webhooks and then invoking queries/mutations) (Server functions overview).
#

What we can’t confirm from the sources: a direct, apples‑to‑apples throughput/latency comparison vs. AWS Lambda or Cloudflare Workers, or vs. Supabase+Prisma Accelerate. The docs emphasize Convex’s low-latency V8 execution and horizontal scaling of function execution but don’t publish specific benchmarks in these sources. If you need sustained high-concurrency webhook handling, Convex’s Funrun scaling is designed for that; for exact limits and sizing, you’d load test and/or consult Convex support on the Pro plan (Impact).

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@thorny girder Kapa.ai is still learning and improving, please let me know how I did by reacting below.

thorny girder
#

What are the downsides of using convex?

#

@latent stump

latent stumpBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

Sorry @thorny girder, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:

Perhaps try again in 15mins?

thorny girder
#

What are the downsides of using convex? @latent stump

latent stumpBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

Some downsides and limitations called out in the sources:

#
  • Query scan limits for transactional/reactive queries make very large result sets challenging (e.g., 16,384 document scan limit). This can complicate enterprise-scale OLTP/OLAP-style workloads and large, ad‑hoc reporting; the team suggests using an external OLAP engine today, with “stale” queries and embedded DuckDB planned but not yet generally available (Discord: enterprise scale thread).
  • Pricing clarity has been a concern for some users (function call counts, action compute). The team acknowledged the pricing page needs a revamp and that surprises can occur without clear visibility, especially at scale (Discord: pricing thread).
  • Self-hosting is single-node by default and puts ops burdens (scaling, upgrades/migrations, backups, monitoring) on you; scaling beyond a single machine requires modifying the open-source backend. There’s no official support plan for self-hosting currently (Self-hosting overview, Voilà! caveats).
  • Local development limitations: no public URL without a proxy, specific Node.js version for node actions, and dashboard issues with Safari/Brave unless configured (Local deployments limitations).
  • Workflow component limitations: 1 MiB total step I/O per execution, determinism constraints when changing step structure, console log duplication, and need to put side effects in steps (Workflow limitations).
#
  • If you’re tied to a legacy relational schema or deep enterprise integrations, Convex may not be the best fit compared to traditional RDBMS stacks (Top 5 real-time databases compared).
  • Compared to managed relational stacks, Convex abstracts servers and caching, which is a positive, but you relinquish low-level control typical of bespoke backend/server/database setups (Convex vs. relational DBs).
#

Note: Some users evaluating enterprise-scale needs chose other platforms due to the above limits; Convex has stated plans for improved OLAP support (stale queries soon; embedded DuckDB later), but timelines are not guarantees (Discord: enterprise scale thread).

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: