# A thin Prolog wrapper for SQLite
**URL:** https://swi-prolog.discourse.group/t/a-thin-prolog-wrapper-for-sqlite/9582
**Category:** Pack
**Created:** [April 25, 2026, 8:12am UTC](https://swi-prolog.discourse.group/t/a-thin-prolog-wrapper-for-sqlite/9582 "2026-04-25T08:12:31Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@Boris](https://swi-prolog.discourse.group/u/Boris)
#### Post date: [April 25, 2026, 8:12am UTC](https://swi-prolog.discourse.group/t/a-thin-prolog-wrapper-for-sqlite/9582/1 "2026-04-25T08:12:31Z")
I now published a new version (1.1) of the add-on pack swiplite. This is a thin, low-level Prolog wrapper for SQLite.
The repository is at: [GitHub - borisvassilev/swiplite: SQLite for SWI-Prolog · GitHub](https://github.com/borisvassilev/swiplite)
I published this version using:
```prolog
$ swipl pack publish https://github.com/borisvassilev/swiplite/archive/V1.1.zip
```
I have been using this version for about half a year and it seems stable. I cannot tell if it is useful to anyone but me but then again, you never know. It offers a distinct set of features not available in [prosqlite](https://www.swi-prolog.org/pack/list?p=prosqlite). Most importantly, it offers bind variables for your SQL queries. You can find [SQLite-specific information in the repository](https://github.com/borisvassilev/swiplite/blob/44a8f4e982ade8c2d253c19c145ecb8aad902dab/SQLITEDOC.md).
See [the README](https://github.com/borisvassilev/swiplite#background) for a justification for the existence of this library.
You can install it with the package manager:
```prolog
?- pack_install(swiplite).
```
This will download it and attempt to compile the foreign code. You need a recent SQLite installed on your system, and a C compiler. Currently, only Linux and MacOS are supported. For MacOS I strongly recommend [installing SQLite from Homebrew](https://formulae.brew.sh/formula/sqlite) since MacOS comes with SQLite, but the version is both out-of-date and compiled weirdly (probably for backwards compatibility).
It should be possible to use the SQLite amalgamation for a custom build, please see the README and the code.
Once you install it, you can load it and do a smoke test:
```prolog
?- use_module(library(sqlite)).
true.
?- sqlite_version(V).
V = '3.53.0'.
```
Enjoy! (responsibly)
---
### Author:  [@swi](https://swi-prolog.discourse.group/u/swi)
#### Post date: [April 26, 2026, 4:49am UTC](https://swi-prolog.discourse.group/t/a-thin-prolog-wrapper-for-sqlite/9582/2 "2026-04-26T04:49:36Z")
Nice. Since you can bind variables (e.g. parametrized sql) I would suggest you run fast\_term\_serialized/2 and store it as a blob in sqlite. That is much better than stringifying.
---
### Author:  [@Boris](https://swi-prolog.discourse.group/u/Boris)
#### Post date: [April 26, 2026, 5:19am UTC](https://swi-prolog.discourse.group/t/a-thin-prolog-wrapper-for-sqlite/9582/3 "2026-04-26T05:19:53Z")
Hi, thank you for the interest and the suggestion. I have considered many different possibilities over the last year but I don’t think I considered this in particular. Much appreciated!
The one biggest hurdle has been the lack of another user 😃 which basically means that I have had to make uninformed design choices and then also implement them.
Which specific data types do you think should be treated like this?
PS: I seem to remember that very early on I thought I could treat _all_ Prolog terms like this. I do not remember why I changed my mind. Maybe back then I wanted to be able to inspect the database without any Prolog? Hmm… I need to think about it and get back to you.
PPS: the reason for doing any of this was to use relational database features that are not immediately available in SWI-Prolog: disk persistence by default, and more importantly, referential integrity through a (somewhat) normalized schema and foreign keys. This is why the current default for swiplite is to enable foreign keys unless the client code insists otherwise. (Another symptom is how I have differentiated in the interface between “no results”, “one result”, and “many results” queries. I don’t think many programmers would consider this a good design.)
It is certainly possible to do it if the schema doesn’t know about the data but I am guessing that early on I decided this is going to be difficult.
This whole thing ended up being a hobby project and it really shows 😃 I shared it publicly for reasons I do not fully understand myself.
---
### Author:  [@peter.ludemann](https://swi-prolog.discourse.group/u/peter.ludemann)
#### Post date: [April 26, 2026, 9:12am UTC](https://swi-prolog.discourse.group/t/a-thin-prolog-wrapper-for-sqlite/9582/4 "2026-04-26T09:12:13Z")
FWIW, [pack(rocks-predicates)](https://github.com/JanWielemaker/rocks-predicates) uses term\_string/2 and not fast\_term\_serialized/2 … you’d have to ask @jan why he made that choice.
---
### Author:  [@Boris](https://swi-prolog.discourse.group/u/Boris)
#### Post date: [April 26, 2026, 9:21am UTC](https://swi-prolog.discourse.group/t/a-thin-prolog-wrapper-for-sqlite/9582/5 "2026-04-26T09:21:03Z")
It doesn’t seem that term reading and writing is ever going to be the bottleneck in anything I do. In my experience with this hobby library of mine, swiplite, the only bottleneck is writing to disk and the inevitable locks. Doing many inserts with “autocommit”; vs. putting them in a transaction is the only “optimization” that seems to matter.