A CGo-free port of SQLite/SQLite3

6/7/2026 at 7:22:13 PM

I was confused a few weeks ago. Check out the go pkg: https://pkg.go.dev/modernc.org/sqlite

1. gitlab.com/cznic/sqlite is the primary repo

2. github.com/cznic/sqlite was the github mirror but it moved

3. github.com/mordernc-org/sqlite is the read-only mirror of the primary repo

Cheers!

by jsherer

6/7/2026 at 10:01:43 PM

> 3. github.com/mordernc-org/sqlite is the read-only mirror of the primary repo

Typo, should be: github.com/modernc-org/sqlite

by porjo

6/7/2026 at 10:24:57 PM

There's also my take on this [1], which does machine translation from C to Go via Wasm using [2].

It's a somewhat less faithful translation, since I manually ported the VFS (SQLite OS abstraction layer).

OTOH, each SQLite connection is sandboxed (can't access/corrupt Go memory, or other SQLite connections). And it should run everywhere Go runs.

1: https://github.com/ncruces/go-sqlite3

2: https://github.com/ncruces/wasm2go

by ncruces

6/7/2026 at 6:49:30 PM

Seems like there are some trademark issues with just calling this SQLite.

by yodon

6/8/2026 at 12:16:36 AM

It's cznic/sqlite in Go-land; this is just a quirk of HN titling.

by tptacek

6/8/2026 at 12:30:30 AM

A quirk of this submitter's choice? We've seen it several times before without the trademark violation:

2023: Go port of SQLite without CGo (255 points, 118 comments) https://news.ycombinator.com/item?id=35488980

2020: Cznic/sqlite: Sqlite in pure Golang (no CGO) (6 points, not interesting for discussion.. this project is old) https://news.ycombinator.com/item?id=24358826

(7 other similar submissions)

by gnabgib

6/8/2026 at 12:40:46 AM

I don't care, I just wrote to clarify the project, in the Go community, isn't called "sqlite". That wouldn't make sense; there are multiple (pin-compatible) sqlite interfaces for Go.

by tptacek

6/7/2026 at 7:26:15 PM

SQL would have been SEQL if not for trademark issues, the torch is passed

by downrightmike

6/7/2026 at 11:26:51 PM

SEQUEL. It was a play on QUEL [https://en.wikipedia.org/wiki/QUEL_query_languages].

by 9rx

6/7/2026 at 7:48:18 PM

The readme really lacks the answer to the "why" question. What's the use case, why should I prefer it over real sqlite?

by usrnm

6/7/2026 at 8:10:07 PM

The "port" terminology is misleading; this is real SQLite, compiled from C to Go using https://gitlab.com/cznic/ccgo/-/tree/master/v4 (by the same author; this library is its most widely used application). The use case is that a lot of Go codebases prefer to completely eschew FFI because a lot of the nice properties of Go's tooling and whatnot (cross-compilation is trivial, binaries are automatically static on Linux, etc.) only hold if the entire build is pure Go.

by ameliaquining

6/7/2026 at 9:04:27 PM

So because of Go's design mistakes.

by ivanjermakov

6/8/2026 at 12:14:57 AM

No. A mistake is unintentional. Go's rejection of a C runtime dependency is a deliberate trade off, and one that has served it well for its design goals.

by 10000truths

6/7/2026 at 9:25:10 PM

Compared to what? Other languages AFAIK don't offer those properties at all, except I guess Zig.

by ameliaquining

6/8/2026 at 12:17:39 AM

The biggest reason you'd want a cgo-free sqlite is if you're cross-compiling; for instance, from your macOS dev laptop to an x64 dev server.

by tptacek

6/8/2026 at 9:18:19 AM

Exactly. Even though your m5 max laptop will run the x86 binary just fine, if you don't compile it for arm, your m5 max laptop drops most of its speed and only has the same performance as an x86 server ...

by spwa4

6/8/2026 at 2:02:02 AM

If your codebase is pure golang it’s trivial to cross compile for different OSs (aside from binary signing on macOS). If you add some kind of C code you have to jump through a bunch of hoops to get a binary. Funny enough, I was looking for this exact project for that reason last week.

by 0x20cowboy

6/7/2026 at 8:05:07 PM

Because it's cgo-free maybe?

by blubber

6/7/2026 at 8:11:49 PM

Cgo overhead is trivial compared to what's happening inside a database engine, totally not worth it

by usrnm

6/7/2026 at 8:32:29 PM

It's not just about overhead/performance. cgo-free means no need to set up a cross-compiler if targeting other devices. Just "go build" with the right GOARCH and GOOS will let you compile a binary that will run on most devices.

by anupcshan

6/7/2026 at 8:38:19 PM

Static builds cannot have cgo too if I am not mistaken.

by dizhn

6/7/2026 at 9:07:47 PM

The following go flags let you build statically-linked cgo binaries, provided that all the C libraries that you're using support static linking and don't call the NSS functions in glibc:

-tags netgo,osusergo -linkmode external -extldflags -static

I regularly compile (cross-compile, even) static Go binaries that use the cgo sqlite package. But it's certainly a lot simpler if you can avoid cgo.

by agwa

6/7/2026 at 8:38:01 PM

I'm pretty sure that C is a much better choice if you really care about binaries that run on most devices

by usrnm

6/7/2026 at 8:44:46 PM

Depends on what you mean by "most". The cross compile story for Go is far superior to C for the platforms it supports.

by Ferret7446

6/7/2026 at 9:59:33 PM

This project is for using Sqlite from Go code. It is not a general purpose replacement.

by anupcshan

6/7/2026 at 8:28:27 PM

Absolutely not. Maybe runtime overheads are minimal, but builds are so much harder to do. And yes, you need to figure it out maybe once, but it is still a lot more effort than just pulling in a new dependency. Now repeat that same effort for every new application, vs pulling that into every new application.

by figmert

6/7/2026 at 8:35:41 PM

that’s really not true when the database is all in memory, statements are prepared, and so on.

but the overheads also stack up, the database/sql api is fairly allocation heavy too unless you do a lot of work and that friction increases quite a bit with the ffi boundary.

this is not to suggest “modernc is faster” - it’s not for a lot a workloads.

there are opportunities for optimization all over both approaches.

by raggi

6/7/2026 at 6:47:30 PM

So is this a handmade port vs the translated port done by modernc?

by pstuart

6/7/2026 at 6:59:27 PM

modernc is the name of the GitHub fork (identical repo) of the same project. This is machine translated, not hand written.

by vicek22

6/8/2026 at 9:21:16 AM

It's machine translated with TLA, tested, and finished by adding a few extra pure go mechanisms (such as Go code-backed virtual tables)

by spwa4

6/8/2026 at 11:01:10 AM

This project seems to get shared every month or so. It's really sad that HN's signal to noise has fallen this hard... While I continue to have it in my feed, I'm more and more opening up Reddit since it just feels more robust now adays.

by pjjpo

6/7/2026 at 7:36:01 PM

[flagged]

by ftgffsdddr

6/7/2026 at 8:16:03 PM

I agree that it would be better to not require JavaScripts. (But, I think it can be helpful to have mirrors on other services as well, for this and other reasons.)

However, there are some work arounds to some situations. Git could (presumably) still be used, if you have that (although you might not want the entire repository and only some files, so that is a possible issue with this). If you have a URL of a specific file that you can change "blob" to "raw" in the URL to access the raw file (this works on other services as well and is not specific to Gitlab). For commits, you can add ".patch" or ".diff" on the end of the URL (this also is not specific to Gitlab).

by zzo38computer

6/8/2026 at 7:19:05 AM

Just use a real web browser or enable JS, it's not that hard buddy. "Why do you keep hitting yourself?"

by qweqwe14

6/7/2026 at 7:41:54 PM

[flagged]

by slopinthebag

6/7/2026 at 8:10:15 PM

[flagged]

by bananamogul

6/7/2026 at 8:58:43 PM

No it doesn't.

by wild_egg