HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
mattn
go-sqlite3
C2012–2026
mattn / go-sqlite3

go-sqlite3

sqlite3 driver for go using database/sql

39Distinct people
43Mentions
1Explicit recommenders
9.3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

sqlite3 driver for go using database/sql

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

I tried TDM-GCC. In my experience, certain aspects increase risks when using go: 1. go is buggier for Windows than Linux and FreeBSD, even though they are all "first class"…

montyedwards used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

Show HN: I created a library for correctly using SQLite in Go programs direct repository linkInformational

The discussion centers on a new Go library for SQLite usage, with one user suggesting an alternative pure Go implementation and noting limited applicability, while another offers general praise. The conversation highlights specific technical considerations regarding library compatibility rather than evaluating the core tool's quality.

2 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3

Mentions over time

HN mentions by year43 dated mentions

Observed mentions: 2012-09-10 14:42:16 UTC to 2026-01-23 13:49:03 UTC.

02462012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20122013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC202
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC101
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC101
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC101
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC303
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC404
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC202
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC606
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC707
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC615
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC606
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
go-sqlite3 Sponsors This project is proudly sponsored by: Latest stable version is v1.14 or later, not v2. Description A sqlite3 driver that conforms to the built-in database/sql interface. Supported Golang version: See .github/workflows/go.yaml. This package follows the official Golang Release Policy. Overview go-sqlite3 Description Overview Installation API Reference Connection String DSN Examples Features Usage Feature / Extension List Compilation Android ARM Cross Compile Compiling Linux Alpine Fedora Ubuntu macOS Windows Errors User Authentication Compile Usage Create protected database Password Encoding Available Encoders Restrictions Support User Management SQL Examples *SQLiteConn Attached database Extensions Spatialite FAQ License Author Installation This package can be installed with the go get command: go get github.com/mattn/go-sqlite3 go-sqlite3 is cgo package. If you want to build your app using go-sqlite3, you need gcc. Important: because this is a CGO enabled package, you are required to set the environment variable CGO_ENABLED=1 and have a gcc compiler present within your path. API Reference API documentation can be found here. Examples can be found under the examples directory. Connection String When creating a new SQLite database or connection to an existing one, with the file name additional options can be given. This is also known as a DSN (Data Source Name) string. Options are append after the filename of the SQLite database. The database filename and options are separated by an ? (Question Mark). Options should be URL-encoded (see url.QueryEscape). This also applies when using an in-memory database instead of a file. Options can be given using the following format: KEYWORD=VALUE and multiple options can be combined with the & ampersand. This library supports DSN options of SQLite itself and provides additional options. Boolean values can be one of: 0 no false off 1 yes true on Name Key Value(s) Description UA - Create _auth - Create User Authentication, for more information see User Authentication UA - Username _auth_user string Username for User Authentication, for more information see User Authentication UA - Password _auth_pass string Password for User Authentication, for more information see User Authentication UA - Crypt _auth_crypt SHA1SSHA1SHA256SSHA256SHA384SSHA384SHA512SSHA512 Password encoder to use for User Authentication, for more information see User Authentication UA - Salt _auth_salt string Salt to use if the configure password encoder requires a salt, for User Authentication, for more information see User Authentication Auto Vacuum _auto_vacuum | _vacuum 0 | none1 | full2 | incremental For more information see PRAGMA auto_vacuum Busy Timeout _busy_timeout | _timeout int Specify value for sqlite3_busy_timeout. For more information see PRAGMA busy_timeout Case Sensitive LIKE _case_sensitive_like | _cslike boolean For more information see PRAGMA case_sensitive_like Defer Foreign Keys _defer_foreign_keys | _defer_fk boolean For more information see PRAGMA defer_foreign_keys Foreign Keys _foreign_keys | _fk boolean For more information see PRAGMA foreign_keys Ignore CHECK Constraints _ignore_check_constraints boolean For more information see PRAGMA ignore_check_constraints Immutable immutable boolean For more information see Immutable Journal Mode _journal_mode | _journal DELETETRUNCATEPERSISTMEMORYWALOFF For more information see PRAGMA journal_mode Locking Mode _locking_mode | _locking NORMALEXCLUSIVE For more information see PRAGMA locking_mode Mode mode rorwrwcmemory Access Mode of the database. For more information see SQLite Open Mutex Locking _mutex nofull Specify mutex mode. Query Only _query_only boolean For more information see PRAGMA query_only Recursive Triggers _recursive_triggers | _rt boolean For more information see PRAGMA recursive_triggers Secure Delete _secure_delete boolean | FAST For more information see PRAGMA secure_delete Shared-Cache Mode cache sharedprivate Set cache mode for more information see sqlite.org Synchronous _synchronous | _sync 0 | OFF1 | NORMAL2 | FULL3 | EXTRA For more information see PRAGMA synchronous Time Zone Location _loc auto Specify location of time format. Transaction Lock _txlock immediatedeferredexclusive Specify locking behavior for transactions. Writable Schema _writable_schema Boolean When this pragma is on, the SQLITE_MASTER tables in which database can be changed using ordinary UPDATE, INSERT, and DELETE statements. Warning: misuse of this pragma can easily result in a corrupt database file. Cache Size _cache_size int Maximum cache size; default is 2000K (2M). See PRAGMA cache_size Statement Cache Size _stmt_cache_size int Maximum number of prepared statements cached per connection; default is 0 (disabled). Note that sql.DB is a connection pool, so each connection maintains its own independent cache. DSN Examples file:test.db?cache=shared&mode=memory Features This package allows additional configuration of features available within SQLite3 to be enabled or disabled by golang build constraints also known as build tags. Click here for more information about build tags / constraints. Usage If you wish to build this library with additional extensions / features, use the following command: go build -tags "<FEATURE>" For available features, see the extension list. When using multiple build tags, all the different tags should be space delimited. Example: go build -tags "icu json1 fts5 secure_delete" Feature / Extension List Extension Build Tag Description Additional Statistics sqlite_stat4 This option adds additional logic to the ANALYZE command and to the query planner that can help SQLite to chose a better query plan under certain situations. The ANALYZE command is enhanced to collect histogram data from all columns of every index and store that data in the sqlite_stat4 table.
Read the full README on GitHub

What Hacker News says

43 sources
Which SQLite Go library do you use? My biggest pain with using SQLite in Go is often the libraries and the reliance of CGO which is what puts me off using Turso Edit: Looking at the go mod file I noticed github.com/mattn/go-sqlite3 which I think is a C wrapper library so I'm assuming you rely on CGO for compiling
In Turso is an in-process SQL database, compatible with SQLite
Oh fun. Since this pokes at LLM I'll share my use case from last week. I built a similar(ish) tool locally (for personal use) as a CLI with an LLM. I download transactions from my bank and credit card, have it load them into a sqlite database, do some transformations (categorizing, grouping, excluding), and bottle up each command as a cli sub-command or flag. I used go, cobra, and the charm libs (to help with interactive labeling). I spent about a day on it to get it roughly usable, so I can drop in my updated transactions next month and get a basic report. Since the output is sqlite database and cli commands, I can also use claude code to ask it stuff, which was interesting because my original plan was to do all the asking myself and just have claude build the cli tool. It works decently. I got out what i needed and fought very very hard
Read the rest
to not go more all in / code dive, etc. I just needed my monthly expense totals, ordered, with some clean-up. The code is so-so, but it mostly got things working in a few shots. Claude being able to iteratively run commands / issue queries while it worked was key to it getting functional, I think. I love that it runs local and spits out plain text for tables and such; to share with my wife i copy pasted some of the output to a text document then added some comments (markdown). If I hacked on it more, I'd probably re-work the architecture a bit; I think coming up with a good design about how to ingest idempotently, and then how you want to transform transactions (i.e. in place, vs setting up rules / overrides and then generating a computed transactions table) is most important. After each mini feature having the LLM document its usage in the README, and of course committing, was key. It made it very easy to ditch conversations and start new ones, and point to the README / examples (as opposed to compacting prior conversation). I think your tool at $5 is a great value; I had TONS of fun making the CLI app but it still took me a few hours of focused work in the end spread over a day, and relied on me having very basic prior experience to help steer it. I bet you can charge more while still keeping the product focused / maintenance low, and absolutely think there's a strong need for it -> While I am super tempted to get crazy with my local app and / automating calculations (etc) ultimately just seeing the money in / out, a few categories that I can sum up (groceries, eating out), and the top 15 expenses, that's really all we need to get our budget in place. Kudos on building a real product, esp. on figuring out how to keep it focused, finding the niche, and recognizing the opportunity to capitalize! EDIT: My actual deps list here. require ( github.com/BurntSushi/toml v1.5.0 github.com/charmbracelet/bubbles v0.21.0 github.com/charmbracelet/bubbletea v1.3.5 github.com/charmbracelet/huh v0.7.0 github.com/charmbracelet/lipgloss v1.1.0 github.com/charmbracelet/log v0.4.2 github.com/mattn/go-sqlite3 v1.14.22 github.com/spf13/cobra v1.10.1 )
In Show HN: Write It Down – Personal finance tracker
> The following platforms unfortunately no longer get prebuilt binaries for download at syncthing.net and on GitHub, due to complexities related to cross compilation with SQLite: dragonfly/amd64 illumos/amd64 and solaris/amd64 linux/ppc64 netbsd/* openbsd/386 and openbsd/arm windows/arm I'm surprised they're dropping windows/arm considering that seems to be the direction things are moving in. I don't understand why they chose to use github.com/mattn/go-sqlite3 instead of modernc.org/sqlite
In Syncthing 2.0 Released
> Edit: Based on your benchmarks repo (https://github.com/trailbaseio/trailbase-benchmark/tree/main...) note that compiling PocketBase with `CGO_ENABLED=1` is no longer enough to kick in the github.com/mattn/go-sqlite3 driver and you need to enable it manually as shown in the db_cgo.go in our benchmarks OR like in https://pocketbase.io/docs/go-overview/#github-commattngo-sq... (the reason for this change was to avoid the "multiple definition" linker errors). FWIW, I did this locally (also happy to fork PB and check it in, certainly aids transparency). I've already updated the numbers in the benchmark doc but will continue to try squeeze more out of it. As to 4x, my concurrency levels are significantly lower which could certainly explain it. Is PB juggling multiple connections increasing write lock congestion or are you serializing access,
Read the rest
e.g. via a worker thread? Also happy to chat more (feel free to send me an email), I certainly want PB to have the best possible representation and maybe we can even speed things up on both sides
In TrailBase: Sub-millisecond open-source application base with Rust, SQLite and V8
> I'm not sure this is expected but it didn't seem to make much of a difference with my setup I expect it to be faster but it is also possible that maybe in your specific collection and execution scenario it somehow perform worst, or at least not the same as in my benchmarks, I'm not sure. The ~4x mentioned speed up is based on the tests for Hetzner CAX41 with the CGO driver when creating 50k records with 500 concurrent clients: Old (58.409064001s): https://github.com/pocketbase/benchmarks/blob/54140be5fb0102... New (13.580098262s): https://github.com/pocketbase/benchmarks/blob/7df0466ac9bd62... --- Edit: Based on your benchmarks repo (https://github.com/trailbaseio/trailbase-benchmark/tree/main...) note that compiling PocketBase with `CGO_ENABLED=1` is no longer enough to kick in the github.com/mattn/go-sqlite3 driver and you need to ena
Read the rest
ble it manually as shown in the db_cgo.go in our benchmarks OR like in https://pocketbase.io/docs/go-overview/#github-commattngo-sq... (the reason for this change was to avoid the "multiple definition" linker errors).
In TrailBase: Sub-millisecond open-source application base with Rust, SQLite and V8
ncruces·Apr 30, 2024Submission

Show HN: Roast my SQLite encryption at-rest

SQLite encryption at-rest is a hot requested feature of both the “default” CGo driver [1] and the transpiled alternative driver [2]. So, this is a feature I wanted to bring to my own Wasm based Go driver/bindings [3]. Open-source SQLite encryption extensions have had a troubled last few years. For whatever reason, in 2020 the (undocumented) feature that made it easy to offer page-level encryption was removed [4]. Some solutions are stuck with SQLite 3.31.1, but Ulrich Telle stepped up with a VFS approach [5]. Still, their solution seemed harder than something I'd want to maintain, as it requires understanding the structure of what's being written to disk at the VFS layer. So, I looked at full disk encryption for something with less of an impedance mismatch. Specifically, I'm using the Adiantum tweakable and length-preserving encryption (w
Read the rest
ith 4K blocks, matching the default SQLite page size), and encrypting whole files (rather than page content). I'm not a cryptographer, so I'd really appreciate some roasting before release. There is nothing very Go specific about this (apart from the implementation) so if there are no obvious flaws, it may make sense to port it to C/Rust/etc and make it a loadable extension. [1] https://github.com/mattn/go-sqlite3/pull/1109 [2] https://gitlab.com/cznic/sqlite/-/issues/105 [3] https://github.com/ncruces/go-sqlite3/issues/55 [4] https://github.com/sqlite/sqlite/commit/b48c0d59 [5] https://github.com/utelle/SQLite3MultipleCiphers
99 points · Open discussion
SQLite is great. I've also recently settled on it as a key-value store, after considering a few purpose-built key-value solutions. Turns out that it's really easy to make SQLite work as a key-value store, but very difficult to make key-value stores relational, if you ever need to. Just be careful with `:memory:` databases. From the mattn/go-sqlite3 FAQ[1]: > Each connection to ":memory:" opens a brand new in-memory sql database, so if the stdlib's sql engine happens to open another connection and you've only specified ":memory:", that connection will see a brand new database. A workaround is to use "file::memory:?cache=shared" (or "file:foobar?mode=memory&cache=shared"). Every connection to this string will point to the same in-memory database. I noticed strange behaviors with just `:memory:` where tables would disappear at random, and th
Read the rest
is workaround helped. Make sure to use a unique filename as the `file:` value, especially if using this in tests. [1]: https://github.com/mattn/go-sqlite3#faq
In Replacing Complicated Hashmaps with SQLite
It doesn't support everything. No driver likely does. An example of one thing missing is the pointer passing interface which limits the ability to create complex extensions. If support was added, the way function creation and virtual tables where wrapped would make it hard to use. But even more trivial things like a decent interface to incremental blob IO have been left unaddressed. https://www.sqlite.org/bindptr.html https://github.com/mattn/go-sqlite3/issues/239
In I benchmarked six Go SQLite drivers
> One issue I've run into while using strict tables is that since sqlite does not (yet?) have a dedicated type for timestamps, a driver like github.com/mattn/go-sqlite3 use the typename in the schema to determine when a column can be converted to a native time datatype. But STRICT tables only allow 6 specific typenames: INT, INTEGER, REAL, TEXT, BLOB, ANY I wish they’d implement CREATE DOMAIN, like Postgres has. Using it you can define a named custom type from a base type, optionally with associated CHECK constraints. A minimal implementation would skip the constraints (and DEFAULT and collation) and just let you do CREATE DOMAIN timestamp AS INT (or TEXT if you’d rather do it that way), and thereafter STRICT tables could have timestamp as column type Previous comment of mine which explains this in more detail: https://news.ycombinator.co
Read the rest
In The Design of SQLite4 (2014)

Showing the 15 most recent of 43 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.