We hit a stable crash in one of our Go services.
The setup was simple:
<pre><code>API -&gt; embedded DuckDB -&gt; MySQL / PostgreSQL / files
</code></pre>
DuckDB is embedded through the Go driver. The driver gives us a normal <code>database/sql</code> interface, but underneath it crosses into DuckDB’s native execution engine.
In many Go services, the best answer is simple: avoid CGO if you can.
For DuckDB, that is not really the practical path today. DuckDB itself is a native C++ engine, and the official Go driver uses the native DuckDB library. Static linking does not change the failure domain: native DuckDB code still runs inside the Go process.
A routine federated query triggered <code>SIGSEGV</code> somewhere in the native DuckDB execution path.
The client saw:
<pre><code>curl: (52) Empty reply from server
</code></pre>
The journal showed:
<pre><code>stream-api: terminated with signal 11 (SEGV), core dumped
</code></pre>
The API process was gone because that is where the call into native DuckDB execution happened.
<h2><code>recover()</code> is the wrong layer</h2>
In normal Go code, I would not reach for <code>recover()</code> here either. Return errors where possible. Let unexpected panics expose bugs. Fix them.
This case was different: the process did not hit a Go panic. It died in native code called through CGO.
<code>recover()</code> only works with Go
<pre><code>defer func() {
 if r := recover(); r != nil {
 // too late for a native SIGSEGV
 }
}()
</code></pre>
The real problem is the failure domain.
Our API process was doing three jobs:
<ol>
<li>Serve HTTP</li>
<li>Manage request and state lifecycle</li>
<li>Run analytical SQL through an embedded native engine</li>
</ol>
The first two are normal Go application work. The third crosses into native execution.
<h2>The fix is a process boundary</h2>
<pre><code>client -&gt; API -&gt; supervised query worker -&gt; DuckDB -&gt; data sources
</code></pre>
If DuckDB crashes, only the worker should die.
The API should stay alive, mark the query as failed, and start a fresh worker for the next request.
The worker protocol can be simple: HTTP, stdio, gRPC, <code>go-plugin</code>, or an existing message bus if one is already in the stack.
The transport choice matters less than the failure boundary: native execution no longer shares the API process.
This is not about DuckDB being bad. Embedded DuckDB is still a great starting point: simple deployment, powerful SQL, no separate analytical service.
The lesson is narrower:
&gt; If an embedded native engine executes complex user-driven workloads, do not put it in the same failure domain as your primary API process.
<code>recover()</code> is not the fix.
A supervised worker process is.
Full write-up:
<a href="https://streams.dbconvert.com/blog/embedded-duckdb-api-process-crash/" target="_blank" rel="noopener nofollow">https://streams.dbconvert.com/blog/embedded-duckdb-api-process-crash/</a>

A supportive squad for Go developers who want to dive deeper into what makes Go special. We focus on the language's clean simplicity, powerful concurrency, and reliable performance.

Go Developers

A Go service crashed with SIGSEGV when an embedded DuckDB query triggered a fault in native C++ code via CGO. Since recover() only handles Go panics and cannot catch native crashes, the solution is a process boundary: move DuckDB execution into a supervised worker process separate from the API. If the worker dies, the API survives, marks the query failed, and spawns a fresh worker. The key architectural lesson is that embedded native engines running complex user-driven workloads should not share the failure domain with the primary API process.

Our Go service died from a SIGSEGV in CGO. recover() was not the answer.

This makes sense but IMO, <code>recover()</code> should never have existed or maybe under the <code>unsafe</code> std pkg. It allows really bad patterns, especially from JS devs who use it as a throw/catch mechanism.

Maybe I was not reading it carefully enough, but :
What was the reason for the segmentation fault? DuckDB?
What is the process boundary on your picture?
Thanks.