TOtosh·Oct 11, 2026Submission
apsw: Another Python SQLite Wrapper
89 points · Open discussionrogerbinns
apsw
C2014–2026
rogerbinns / apsw
apsw
Another Python SQLite wrapper
5Distinct people
8Mentions
0Explicit recommenders
955GitHub stars
What to know before exploring
What it is
Another Python SQLite wrapper
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year8 dated mentions
Observed mentions: 2014-03-10 03:06:07 UTC to 2026-10-11 16:58:22 UTC.
* 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
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
8 sourcesMy preferred python wrapper for sqlite is apsw. The maintainer gives a good answer here for why not to use an async interface in most cases: https://github.com/rogerbinns/apsw/discussions/456#discussio...
It really depends on what your workload looks like, but I think synchronous will win most of the time.
In SQLite async connection pool for high-performanceThere is also this, which seems pretty good: https://github.com/rogerbinns/apsw
(haven't tried it yet)
In What's New in SQLite 3.35For a project a few years ago I chose to use apsw:
https://github.com/rogerbinns/apsw
It is a different wrapper for sqlite than the one in the Python standard library. As far as I remember, the stdlib one had some brain-dead choices with regard to concurrency and transactions.
There may have been some other reasons I chose it too, but I don't recall at the minute. The issue is that Python has this spec called "DB-ABI" which is supposed to make all databases look alike. But I don't want that -- I just want to use sqlite!
So 'apsw' is a thin layer on top of sqlite. I'm able to read the sqlite documentation in C, and be reasonably confident in what it's doing. But as far as I remember the Python stdlib version had a bunch of magic in the wrappers that was annoying. I might be mistaken but I think it parsed its own SQL? I think it had
Read the rest
some sort of silly cache of parsed queries, rather than letting you simple store/control that in the application.
I think it also inserted SQL statements for transactions between your own calls!!! I just want the raw SQL to go to sqlite as I intended.
I definitely ran into issues where non-obvious flags to the API increased insert performance by 10x, and it had nothing to do with sqlite itself! So I abandoned it for a thinner wrapper.
Those are the "most recent version" I mentioned. The Visual Studio versions and Python adoption are out of sync. To build for the versions of Python I do, VS 2008, 2010, and whatever Python 3.5 needs. Note that the free versions excluded 64 bit compilation so the resource kit had to be used.
Here is my setup doc https://github.com/rogerbinns/apsw/wiki/Setting-up-a-Windows...
In Welcome to the Python Engineering blogI complain every 6 months about their "releases" page - eg this one for my project https://github.com/rogerbinns/apsw/releases
They unhelpfully add a "Source Code" link, which would be great if that is what it was. Instead it is actually just a zip file of the repository at that tag. But the repository is in a maintainer state, so the "Source Code" isn't useful to an end user because various tools need to be run (eg building help, automake/autoconf, dependencies). The people mislead by Github due to this "Source Code" contact me, not github.
Every six months for several years, I send the email explaining how this doesn't serve anyone's interest, how it hurts, and that I am happy with any solution (eg don't auto add, change the name to make it clear, be able to label an existing file as the "Source Code" etc). I get the usual response
Read the rest
of understanding and sympathy, and vague suggestion that it may be addressed. Three years and counting ...
Amazingly people still use Python 2.3. With source downloads you can't tell what platforms use, but you can with binary downloads. One of my projects is a Python wrapper for SQLite (APSW) for which I also provide compiled Windows binaries for every Python version from 2.3 to the latest, and 64 bit for some of them too. It is very amusing to me that some people want the latest SQLite while using a positively ancient Python version.
Google code shows download counts so you can get an idea of popularity of each release for Windows developers:
https://code.google.com/p/apsw/downloads/list?can=1&q=&colsp...
I've since moved the project to github which doesn't show the download counts for releases.
https://github.com/rogerbinns/apsw/releases
In Python 3.3.5 has been released