Issues with Estuary Pipelines Hanging When Writing to Motherduck – Need Support

·May 18, 2026 03:14 PM·

Hi support team! I've been having some issues with Estuary pipelines writing to Motherduck hanging, and the regular fix of bumping up the duckling size is no longer working. I was told on the Estuary slack channel to get support here as this was a Motherduck issue. I've allowed inbound access to our S3 bucket with the Estuary data to the Motherduck team. Could someone DM me for more details?

👀1

24 comments

· Sorted by Oldest

Connor C.
·
·
Hi Ajit, thanks for reaching out. We've been working on this issue in collaboration with Estuary...they actually just sent over a backend core dump from one of your materializations to help us identify the root cause and work on a fix. Can you try disabling and then enabling the Estuary pipeline? We have seen that this often clears the hanging client-side commit from Estuary and allows the pipeline to run.
Connor C.
·
·
I'll send you a DM for the inbound access so our engineering team can dig deeper. Thanks for setting that up!
✅1
Ajjit N.
·
·
Just disabled and then enabled the materialization, also bumped the service account up to a Jumbo because that helped last time. Happy to provide any info you need!
👍1
Connor C.
·
·
Ajjit N. we have identified the root cause for this issue, and will have a fix shipped in this week's release. Here's what was happening: • We use short-lived tokens for authorization between the client and the server, and they get refreshed automatically when they expire. We identified an extremely rare race condition during this refresh path where, under a specific timing of background activity, the refresh could end up waiting on a lock it already held, producing a deadlock that prevented the client from obtaining a new token and reaching the server. The fix removes that potential loop and will ship with this week's release. Let us know if you have any questions!
🙌1
Ajjit N.
·
·
OK awesome and thanks for the updates! Only thing that might be helpful in the future is some guidance on duckling sizes recommended for either streaming data into Motherduck, or batch processing into MD from Estuary/Fivetran/related tools. Right now our production Azure SQL DBs are around 250 GB, but we batch process CDC data once every 2 hours with Estuary and insert into our Motherduck DBs. These are typically <75 MB of data each every 2 hours. I am not sure whether the service accounts we connect to Estuary should be Normal, or Pulse (or larger with bigger data updates down the line).
Connor C.
·
·
For this use case, I would recommend a standard duckling for your service accounts doing the ingestion
✅1
Ajjit N.
·
·
Connor C., we ran into this issue again in 2 more of our materializations today morning. Our usual fixes of stopping/restarting the materialization and bumping up the service accounts to jumbo do not seem to be working. So not sure what's happening.
Ajjit N.
·
·
Also realize this may not be an issue after the weekly release, roughly when can we expect that? Happy to wait if its just a day or two.
Connor C.
·
·
Hi Ajjit N.! we released the version of the MotherDuck client with the fix a few hours ago, and are chatting with Estuary right now to enable it in their system. Stay tuned!
✅1
Connor C.
·
·
Ajjit N. we just got confirmation that the fix has been rolled out in the Estuary client! Your pipelines will run without encountering this problem now.
Ajjit N.
·
·
Awesome! I will try restarting the one materialization that is still giving me issues.
Connor C.
·
·
Ajjit N. just confirming that things have been running without problems now?
Ajjit N.
·
·
Connor C., a few of my pipelines seem to have hung again last night. I restarted the tasks on Estuary and upgraded to Jumbo compute instances which fixed it temporarily. But as of today morning they seem to be hung again
Ajjit N.
·
·
I still have access enabled to the S3 bucket for the Motherduck team so would appreciate some investigation, also happy to bring this up with the estuary team
Connor C.
·
·
Thanks for letting us know, Ajjit N.. We'll look into this ASAP for you

Connor C.
·
·
Hi Ajit, thanks for reaching out. We've been working on this issue in collaboration with Estuary...they actually just sent over a backend core dump from one of your materializations to help us identify the root cause and work on a fix. Can you try disabling and then enabling the Estuary pipeline? We have seen that this often clears the hanging client-side commit from Estuary and allows the pipeline to run.
Connor C.
·
·
I'll send you a DM for the inbound access so our engineering team can dig deeper. Thanks for setting that up!
✅1
Ajjit N.
·
·
Just disabled and then enabled the materialization, also bumped the service account up to a Jumbo because that helped last time. Happy to provide any info you need!
👍1
Connor C.
·
·
Ajjit N. we have identified the root cause for this issue, and will have a fix shipped in this week's release. Here's what was happening: • We use short-lived tokens for authorization between the client and the server, and they get refreshed automatically when they expire. We identified an extremely rare race condition during this refresh path where, under a specific timing of background activity, the refresh could end up waiting on a lock it already held, producing a deadlock that prevented the client from obtaining a new token and reaching the server. The fix removes that potential loop and will ship with this week's release. Let us know if you have any questions!
🙌1
Ajjit N.
·
·
OK awesome and thanks for the updates! Only thing that might be helpful in the future is some guidance on duckling sizes recommended for either streaming data into Motherduck, or batch processing into MD from Estuary/Fivetran/related tools. Right now our production Azure SQL DBs are around 250 GB, but we batch process CDC data once every 2 hours with Estuary and insert into our Motherduck DBs. These are typically <75 MB of data each every 2 hours. I am not sure whether the service accounts we connect to Estuary should be Normal, or Pulse (or larger with bigger data updates down the line).
Connor C.
·
·
For this use case, I would recommend a standard duckling for your service accounts doing the ingestion
✅1
Ajjit N.
·
·
Connor C., we ran into this issue again in 2 more of our materializations today morning. Our usual fixes of stopping/restarting the materialization and bumping up the service accounts to jumbo do not seem to be working. So not sure what's happening.
Ajjit N.
·
·
Also realize this may not be an issue after the weekly release, roughly when can we expect that? Happy to wait if its just a day or two.
Connor C.
·
·
Hi Ajjit N.! we released the version of the MotherDuck client with the fix a few hours ago, and are chatting with Estuary right now to enable it in their system. Stay tuned!
✅1
Connor C.
·
·
Ajjit N. we just got confirmation that the fix has been rolled out in the Estuary client! Your pipelines will run without encountering this problem now.
Ajjit N.
·
·
Awesome! I will try restarting the one materialization that is still giving me issues.
Connor C.
·
·
Ajjit N. just confirming that things have been running without problems now?
Ajjit N.
·
·
Connor C., a few of my pipelines seem to have hung again last night. I restarted the tasks on Estuary and upgraded to Jumbo compute instances which fixed it temporarily. But as of today morning they seem to be hung again
Ajjit N.
·
·
I still have access enabled to the S3 bucket for the Motherduck team so would appreciate some investigation, also happy to bring this up with the estuary team
Connor C.
·
·
Thanks for letting us know, Ajjit N.. We'll look into this ASAP for you