The key operational question is what happens after the caller leaves. I’d track cancellation propagation, connection release time, server-side query lifetime, and pool saturation separately; a canceled HTTP request is not proof that the database stopped doing work. Those measurements make driver behavior actionable for capacity planning.
Full-stack developer focused on crafting clean, fast, and scalable web products. I love working with Next.js, React, and Tailwind to build modern, user-friendly experiences.
Location
India
Education
Background in English Literature, self-taught coder through courses, books, and hands-on practice.
Pronouns
Lover of clean UI, simple design, and coding workflows that save time for everyone.
Work
Building clean, scalable web solutions that speed up development and simplify design.
Thanks, Alex. That's exactly why I wanted to look beyond what the driver reports. I used a separate observer connection to track the tagged queries in pg_stat_activity and SHOW FULL PROCESSLIST, which let me see what was actually happening on the database side. Across the cancel runs, 38 of 39 queries stopped within 136 ms.
I also measured the impact on pool availability through database-observed connection-seconds and the wait time for the first healthy select 1. I didn't separately measure connection release time from the client pool's perspective, though. A query stopping on the database side and a connection becoming available to the client pool aren't necessarily the same event.
That separation between database cancellation and client-pool availability is the key operational detail. Measuring the first successful checkout after cancellation alongside the server-side stop time would expose whether the pool still has hidden cleanup work that can amplify under load.
Full-stack developer focused on crafting clean, fast, and scalable web products. I love working with Next.js, React, and Tailwind to build modern, user-friendly experiences.
Location
India
Education
Background in English Literature, self-taught coder through courses, books, and hands-on practice.
Pronouns
Lover of clean UI, simple design, and coding workflows that save time for everyone.
Work
Building clean, scalable web solutions that speed up development and simplify design.
I did measure the first successful query after cancellation, though I didn't isolate pool checkout time from the query round trip.
In Test 1, the follow-up select 1 goes through the same one-connection pool immediately after the abort. Across the cancel runs, it completed in 5–105 ms, with one mysql2 run taking 595 ms. In that same run, the database-side query stop took 651 ms. Test 2 measured the same kind of follow-up query with a four-connection pool.
What I haven't measured separately is the time spent waiting for a connection checkout, independent of query execution. I also haven't run repeated cancellation cycles under sustained load. One case worth looking at further was postgres.js 3.4.9: four cancelled promises never settled in every warm-pool run, and the extent of the pool stall varied between runs.
Measuring checkout latency across repeated cancellations under load would be a useful next step.
Your test 2 counts connection-seconds, and there is a second cost on the Node side. With pg, a query nobody cancels still finishes, and the driver turns every row into an object for a client that already left. Our report queries at Oizom touch a million sensor readings, and held as JSON objects that was enough to run a 2 GB droplet out of memory. So an abandoned report there costs heap as well as a pool slot. Did you look at client memory, or only at the database side?
Full-stack developer focused on crafting clean, fast, and scalable web products. I love working with Next.js, React, and Tailwind to build modern, user-friendly experiences.
Location
India
Education
Background in English Literature, self-taught coder through courses, books, and hands-on practice.
Pronouns
Lover of clean UI, simple design, and coding workflows that save time for everyone.
Work
Building clean, scalable web solutions that speed up development and simplify design.
Only the database side, so no, I didn't look at client memory. My queries were sleeps, lock waits and select 1, so each one returned a single row. A cost like the one you're describing wouldn't show up in my measurements.
My tests focused on database-side query activity and the impact on pool availability. They don't cover the additional memory cost on the Node.js side when an abandoned query returns a large result set.
Your million-reading report is a really useful example of why that matters. Measuring heap usage alongside connection-seconds with a large result set would be a good follow-up. Thanks for sharing the real-world numbers from Oizom.
Sleeps and select 1 were the right probes for pool slots. The heap half we fixed apart from cancellation: rows now go straight into two typed arrays, never a million objects, so an abandoned report at Oizom costs two flat buffers. Cancelling it still matters for the connection, which is what your test measures.
Full-stack developer focused on crafting clean, fast, and scalable web products. I love working with Next.js, React, and Tailwind to build modern, user-friendly experiences.
Location
India
Education
Background in English Literature, self-taught coder through courses, books, and hands-on practice.
Pronouns
Lover of clean UI, simple design, and coding workflows that save time for everyone.
Work
Building clean, scalable web solutions that speed up development and simplify design.
Thanks. Two flat buffers are a much better place to be than a million objects.
The connection side is what my test can speak to. If nobody cancels the query, it keeps running on the server, and the connection stays occupied until it finishes. With pg ignoring the signal, the sleep kept running for about 2.5 seconds after the abort. In the pile-up test, the abandoned queries held all four connections until the lock cleared.
I haven't tried this with a real report query, though. My tests used sleeps and lock waits, not large result sets or long-running sorts and aggregates. Testing cancellation with those workloads would show whether the same behavior holds there.
Full-stack developer focused on crafting clean, fast, and scalable web products. I love working with Next.js, React, and Tailwind to build modern, user-friendly experiences.
Location
India
Education
Background in English Literature, self-taught coder through courses, books, and hands-on practice.
Pronouns
Lover of clean UI, simple design, and coding workflows that save time for everyone.
Work
Building clean, scalable web solutions that speed up development and simplify design.
In pg 8.23.1, mysql2 3.24.6 and mariadb 3.5.4, passing an AbortSignal didn't cancel the query. What actually stopped it was a cancel sent from a second connection. postgres.js 4.0.0 was the only version I tested that reads the signal, but even there, a fast query already sent behind a running one wasn't rejected when the signal was aborted.
I haven't tested poolers beyond one PgBouncer check. In transaction mode, a stored backend pid ended up cancelling another client's query, and I haven't gone further than that.
If you've run into this behind PgBouncer or RDS Proxy, or handled cancellation through Prisma, Drizzle or Kysely, I'd really like to hear what you found.
Hey, I'm Hema 👋
Developer, writer, and creator of Dev Opportunity Radar, a weekly series published every Friday on DEV, helping people discover opportunities they might otherwise miss.
Shubhra, another interesting experiment 😃 I honestly wouldn't have thought about what happens to those database queries after a client disconnects. Loved this one!
Full-stack developer focused on crafting clean, fast, and scalable web products. I love working with Next.js, React, and Tailwind to build modern, user-friendly experiences.
Location
India
Education
Background in English Literature, self-taught coder through courses, books, and hands-on practice.
Pronouns
Lover of clean UI, simple design, and coding workflows that save time for everyone.
Work
Building clean, scalable web solutions that speed up development and simplify design.
Thank you, Hema! 😊 I actually wanted to find out what happens in exactly this situation. When a client-side request is aborted, you'd expect the database work to stop too, but that isn't always what happens. In several of the drivers I tested, queries kept running and held connections that other requests needed. I'm really glad you enjoyed reading it!
We're a place where coders share, stay up-to-date and grow their careers.
The key operational question is what happens after the caller leaves. I’d track cancellation propagation, connection release time, server-side query lifetime, and pool saturation separately; a canceled HTTP request is not proof that the database stopped doing work. Those measurements make driver behavior actionable for capacity planning.
Thanks, Alex. That's exactly why I wanted to look beyond what the driver reports. I used a separate observer connection to track the tagged queries in
pg_stat_activityandSHOW FULL PROCESSLIST, which let me see what was actually happening on the database side. Across the cancel runs, 38 of 39 queries stopped within 136 ms.I also measured the impact on pool availability through database-observed connection-seconds and the wait time for the first healthy
select 1. I didn't separately measure connection release time from the client pool's perspective, though. A query stopping on the database side and a connection becoming available to the client pool aren't necessarily the same event.That separation between database cancellation and client-pool availability is the key operational detail. Measuring the first successful checkout after cancellation alongside the server-side stop time would expose whether the pool still has hidden cleanup work that can amplify under load.
I did measure the first successful query after cancellation, though I didn't isolate pool checkout time from the query round trip.
In Test 1, the follow-up
select 1goes through the same one-connection pool immediately after the abort. Across the cancel runs, it completed in 5–105 ms, with onemysql2run taking 595 ms. In that same run, the database-side query stop took 651 ms. Test 2 measured the same kind of follow-up query with a four-connection pool.What I haven't measured separately is the time spent waiting for a connection checkout, independent of query execution. I also haven't run repeated cancellation cycles under sustained load. One case worth looking at further was postgres.js 3.4.9: four cancelled promises never settled in every warm-pool run, and the extent of the pool stall varied between runs.
Measuring checkout latency across repeated cancellations under load would be a useful next step.
Your test 2 counts connection-seconds, and there is a second cost on the Node side. With pg, a query nobody cancels still finishes, and the driver turns every row into an object for a client that already left. Our report queries at Oizom touch a million sensor readings, and held as JSON objects that was enough to run a 2 GB droplet out of memory. So an abandoned report there costs heap as well as a pool slot. Did you look at client memory, or only at the database side?
Only the database side, so no, I didn't look at client memory. My queries were sleeps, lock waits and
select 1, so each one returned a single row. A cost like the one you're describing wouldn't show up in my measurements.My tests focused on database-side query activity and the impact on pool availability. They don't cover the additional memory cost on the Node.js side when an abandoned query returns a large result set.
Your million-reading report is a really useful example of why that matters. Measuring heap usage alongside connection-seconds with a large result set would be a good follow-up. Thanks for sharing the real-world numbers from Oizom.
Sleeps and select 1 were the right probes for pool slots. The heap half we fixed apart from cancellation: rows now go straight into two typed arrays, never a million objects, so an abandoned report at Oizom costs two flat buffers. Cancelling it still matters for the connection, which is what your test measures.
Thanks. Two flat buffers are a much better place to be than a million objects.
The connection side is what my test can speak to. If nobody cancels the query, it keeps running on the server, and the connection stays occupied until it finishes. With
pgignoring the signal, the sleep kept running for about 2.5 seconds after the abort. In the pile-up test, the abandoned queries held all four connections until the lock cleared.I haven't tried this with a real report query, though. My tests used sleeps and lock waits, not large result sets or long-running sorts and aggregates. Testing cancellation with those workloads would show whether the same behavior holds there.
In pg 8.23.1, mysql2 3.24.6 and mariadb 3.5.4, passing an
AbortSignaldidn't cancel the query. What actually stopped it was a cancel sent from a second connection. postgres.js 4.0.0 was the only version I tested that reads the signal, but even there, a fast query already sent behind a running one wasn't rejected when the signal was aborted.I haven't tested poolers beyond one PgBouncer check. In transaction mode, a stored backend pid ended up cancelling another client's query, and I haven't gone further than that.
If you've run into this behind PgBouncer or RDS Proxy, or handled cancellation through Prisma, Drizzle or Kysely, I'd really like to hear what you found.
Shubhra, another interesting experiment 😃 I honestly wouldn't have thought about what happens to those database queries after a client disconnects. Loved this one!
Thank you, Hema! 😊 I actually wanted to find out what happens in exactly this situation. When a client-side request is aborted, you'd expect the database work to stop too, but that isn't always what happens. In several of the drivers I tested, queries kept running and held connections that other requests needed. I'm really glad you enjoyed reading it!