Edge Functions, Honestly: Why They're Probably the Wrong Choice for Your App
By Yaokai Jiang, Founder & CEO, Momen Talk delivered at No-Code Week Frankfurt, June 18, 2026
Why I Gave This Talk
I gave this talk at No-Code Week Frankfurt on June 18, 2026. Before I get into anything, I want to be upfront: I sell a tool in this space. So I won't ask you to trust me — I'll explain how the thing works and let you draw the conclusion yourself. I spent years as a backend engineer at Medallia, studied CS at Cambridge and Carnegie Mellon, and I've been building Momen — a visual app builder now running over 10 million end users — for the last six and a half years. This is the lens I'm bringing.
The talk is about edge functions. Specifically, about why reaching for them by default is probably the wrong move for most of what you're building.
One Example We'll Use All Talk: A Ticketing App
I'm going to use a single scenario throughout. You have a ticketing app for buying tickets. Here's how a purchase works: a fan pays, you charge the card, mark the seat sold, and issue the ticket. The constraints are simple but important: don't sell the same seat twice, and if the card charge fails, issue nothing.
Let's nail down the numbers: 500 seats, $45 per ticket, a hot show that sells out in 40 seconds — roughly 12 buys a second. The fan is in Lagos. The database is in Virginia. That's a 150-millisecond round trip. And one purchase requires five database steps: check availability, charge card, mark seat sold, create a ticket record, associate it with the user.
Keep those numbers in your head. Everything I say next flows from them.
What Is an Edge Function, Actually?
The name "edge" means it's running at the edge of the internet. The way we define the edge is latency — specifically, the first hop that traffic reaches after leaving the user's device. So the device sends traffic, it hits the edge, and from there it travels all the way to your database. That whole middle stretch is what "edge to origin" means.
So an edge function is a small program that runs close to your user — at that first hop. If you're here in Frankfurt, it runs in Frankfurt. If your user is in Lagos, it runs in Lagos. It is not near your server.
And critically, it is stateless. What I mean by stateless is that between two runs, it remembers nothing. An edge function starts up, has no inherent storage, always has to fetch related data from the database, does some logic, issues a response to the user, and then it's gone. In Supabase, the compute is also capped at around 200 milliseconds — go over that and it cuts you off. And there's no standing database connection. Every database call goes over HTTP to another server sitting before the database.
A good analogy: an edge function is a delivery scooter. It is not a kitchen. It's very small. It's not supposed to do the cooking. The problem is that people are using it to do the cooking.
What Actually Happens When a Fan Taps "Buy"
Let's trace what happens when someone in Lagos tries to buy a ticket.
The edge function starts up when the user clicks buy. Then it checks the database: is seat A12 still available? That's one request — 150 milliseconds. It comes back: yes, available. Then the function checks something else, and eventually it's going to issue that ticket. That's a chain of requests to the database. Every single round trip is 150 milliseconds. And during that waiting time, your edge function is blocked. It's not doing anything useful.
Over five round trips, you're looking at 750 milliseconds for a single purchase to complete. That's just the waiting.
And this actually violates one of the foundational principles in software engineering: logic should gravitate towards data. The further your logic runs from the data, the higher the cost incurred at every level. You see this even in AI inference — people are pushing logic closer and closer to the model weights rather than pulling weights in from far away. It's just inefficient.
Lens 1 — Latency: The 150× Problem
The function starts very close to the user, maybe within 15 milliseconds. But the data is still an ocean away. If that same function were running next to the database in the same data center, each of those five steps takes under a millisecond. Five steps: five milliseconds total, instead of 750. That's roughly a 150× difference with the same code, the same logic, just a different location.
If you have a data dependency on the database, you should not really be running it on the edge.
Lens 2 — ACID: The Correctness Problem
The second problem is transactions. Edge functions have no persistent connection to the database, which means they don't have proper transactions.
Here's exactly what this breaks in our ticketing scenario: the function checks if seat A12 is sold. It's not. So it marks A12 as sold and begins the rest of the workflow. Now, during that 750-millisecond window, two people are going through the exact same check simultaneously. Both see A12 as not sold. Both proceed. Both are assigned the same seat.
In the best case, you get an error if you've set up a unique constraint on that table. In the worst case, you end up with last-writer-wins: one person paid for a ticket they never received because their record was overridden by the next write.
That's not an edge case. That's the business logic of almost every transactional app. If you're building anything e-commerce — payments, inventory, bookings — this isn't theoretical. I wrote more about why ACID compliance is non-negotiable for e-commerce here.
Lens 3 — Scalability: Scaling the Scooters Doesn't Scale the Kitchen
People say edge functions are scalable. And they are — if their dependencies are scalable. If your edge function depends only on static data, like something from S3 or client-generated data, there's no scalability issue. Edge functions are nearly infinitely scalable.
But most of the time when you're building apps, your logic depends on data that lives in a database. Your reads and writes go into the database. That is your biggest dependency. And a database is not infinitely scalable.
So you end up building something that scales infinitely, sitting on top of something that is a bottleneck. The edge function scales the easy tier and piles more load on the hard one.
The Bottleneck Is Always the Database
The database is always your bottleneck. It's a single point. It's also the single source of truth. If you've ever used Airtable or similar tools, you know where you hit rate limits — it's the database. State is the thing that doesn't scale horizontally. The database is by definition the shared state of your application. So don't put your logic an ocean away from it. Keep it close. In Momen, all data operations and bindings run server-side, co-located with the database — this is a deliberate design choice for exactly this reason.
This is also why, if you're building with AI-generated code, the architecture matters far more than the prompt. The logic placement problem doesn't disappear just because you didn't type it yourself. I covered this in depth in Stop Prompting, Start Architecting.
So What Are Edge Functions Actually Good For?
I've been bashing on edge functions, so let me be honest about where they're genuinely excellent.
Image resizing on the fly. Say you're serving a thumbnail in a list view on mobile. You don't want to send a 5-megabyte image just to show a thumbnail. An edge function can start up fast, read from S3, resize, and send to the user. There's no interaction with the database whatsoever. Single round trip. It's fantastic. And you get what amounts to infinite compute on demand — something you'd exhaust your CPU doing on a dedicated backend.
Geo and language routing. Instead of sending a request to your backend first, you can redirect directly to different backends depending on where the request comes from. A/B testing works the same way. You're only adding a tiny bit of latency from the edge function itself, and you get all the routing functionality you need.
Blocking bad traffic, caching, rate limiting, rewriting pages. All of these are good use cases.
The common thread in everything they're good at: no database dependency. The data either comes from the client, comes from S3, or comes from something stateless — like the day of the month.
What they're bad at: stateful, multi-step things you want to keep transactional. Anything that guarantees you can't sell the same seat twice. Anything that's chatty with the database — lots of round trips, fetching a little bit at a time, with a chain of dependencies. And anything involving real number crunching that might exceed the compute cap.
The core of most businesses is exactly that list.
The Rule
It's simple:
Stateless and near the user → edge.
Stateful and transactional → next to the data.
The Receipts
I'm not asking you to take my word for this. Vercel — the company most notorious for pushing everything to the edge — has now gone back to recommending Node.js running next to the database. They popularized the edge and they're the ones backing away from it.
Supabase's own documentation describes abrupt function shutdown at the 200ms cap as normal behavior. And CVE-2025-48757 documented roughly 170 AI-built apps leaking user data because of missing access rules — the standard fix for which is to move logic into the database. Which proves the point.
Four Questions to Ask Any Tool — Mine Included
Whenever you're evaluating a backend tool or architecture, ask these four questions:
Latency: where does my logic run relative to my data?
Atomicity: if a purchase fails halfway, what state am I left in?
Isolation: when seat A12 sells twice, what stops it?
Scale: what happens at 12 buys per second, not 1 per minute?
If the answer to question 3 is "the edge function checks first" — it doesn't. The only thing that can actually stop it is the database.
Where Momen Sits — Honestly
We're the opposite of edge-first. We don't have edge functions yet. Everything runs close to the database.
In practical terms: those same five purchase steps take roughly 5 milliseconds, not 750. A purchase is all-or-nothing — we support real ACID transactions on the backend by default. Seat A12 cannot sell twice.
The tradeoff is real and I own it: we're single-region, so users physically far from our data center will feel some latency. And you're learning a visual system rather than just typing a prompt — Momen's backend logic runs as Actionflows, a visual DAG you can read and edit. We chose correctness over flash. I wrote about the full thinking behind this in Why We Built Momen Different.
In terms of cost, one of our customers runs an app with 60,000 users and $800,000 in annual revenue on two dedicated instances — about $350 a month. That's with horizontal Java backend servers and a single Postgres database. The database is the limit — it scales with whatever hardware AWS sells us. By the time you've genuinely outgrown that, you probably have the engineering org to match.
For no-code builders specifically, vibe coding meets no-code is increasingly the workflow — and the same architecture principles apply whether you typed the code or prompted it.
One Test, Tomorrow Morning
Ask your current tool one question: "When seat A12 sells twice — what stops it?"
If the answer is "the edge function checks first," it doesn't. It has to be the database.
Put your logic where the data is.
Yaokai Jiang is the Founder & CEO of Momen. This post is adapted from his talk at No-Code Week Frankfurt, June 18, 2026.
