How it feels to write a GPKG library in 2026 (in Rust!)

Hiroaki Yutani — Sat, 24 Jan 2026 04:53:22 +0000

There are a lot of existing libraries to deal with GeoPackage (GPKG). GDAL is the undisputed champion of the geospatial world. If your target is web browsers, there is GeoPackage JS. Rust? We have gpkg-rs! But, unfortunately, sometimes you still have to write your own one for various reasons.

In my case, the main reason was WebAssembly support. I'm building a browser-side converter for Japanese geospatial data, which converts Shapefiles to GeoParquet and GeoJSON. To add GPKG to that list, I needed some Rust crate for this, but, gpkg-rs doesn't support Wasm.

repository: https://github.com/yutannihilation/ksj2gp

To be fair, it's not gpkg-rs's fault. Only last year did rusqlite, the underlying crate for handling SQLite, gain Wasm support, while gpkg-rs was implemented several years ago.

If I only wanted Wasm support, the easiest route would have been to fork gpkg-rs and update its rusqlite dependency. However, I had two additional ambitions that convinced me to build a new crate from the ground up: rusqlite-gpkg.

Support 3D geometries by using geo-traits instead of geo-types
Write spatial index

You can check out the repository here:

yutannihilation / rusqlite-gpkg

GeoPackage reader/writer built on top of rusqlite.

rusqlite-gpkg

GeoPackage reader/writer built on top of rusqlite.

Web Demo

A simple GitHub Pages demo is available with a button to generate and download a .gpkg file in the browser using a Web Worker + OPFS.

https://yutannihilation.github.io/rusqlite-gpkg/

See web/README.md for implementation details and design notes.

Overview

rusqlite-gpkg provides a small API around the main GeoPackage concepts:

Gpkg represents the whole data of GeoPackage data.
GpkgLayer represents a single layer in the data.
GpkgFeature represents a single feature in the layer.
Value represents a single property value related to the feature.

Apache Arrow support is available behind the arrow feature flag. You can find some example codes in the bottom of this README.

The library focuses on simple, explicit flows. You control how layers are created and which property columns are present.

Browser usage (to_bytes / from_bytes)

Web environments often cannot access files directly (OPFS can be used by rusqlite…

View on GitHub

Enough with the backstory. Let’s get into the heart of the matter: What does it actually feel like to write a GeoPackage library in 2026?

(Disclaimer: this post discusses GPKG as a vector data format. I have not yet explored how it works as a raster data format.)

The Age of LLMs

No "writing a library in 2026" post can skip mentioning AI. I actually used Codex a lot, especially for adding tests and documentation. If I were an LLM expert, I would have inserted lengthy advice here. But, it is fortunate that I'm so poor at LLM that we can skip this boring part and save some time. :)

GPKG Is SQLite

Did you know GPKG is built on top of SQLite? More specifically, did you know a .gpkg file is just a plain SQLite database? There is no magic. If you read the specification, you can find GPKG is designed to be "portable" in the sense that it only requires SQLite to read the data.

Unlike other geospatial formats like GeoParquet, GPKS's specification doesn't define a binary file format (except for the geometry column). Instead, it defines SQLs to define the tables and triggers.

There are pros and cons.On the positive side, we don't need to implement a parser for the binary! We can just rely on some existing SQLite client/library. If you have implemented a parser for some binary format, you should realize how much this makes the code easier.

However, this also means we need an SQLite library as a dependency. At least, I cannot imagine writing a full SQLite reader (and a writer) from scratch. This makes build harder especially in case of Rust; Turso is a promising pure-Rust implementation of SQLite, but it's not ready at the moment. As explained above, rusqlite is ready to use. But, as it depends on libsqlite and needs to bundle it in many cases.

Writer

Reading a GPKG file can be done without knowing geospatial. I mean, the data needs to be interpreted by some other libraries that knows geospatial, but the reader can just extract and pass the WKB binary and/or some metadata like SRID.

Writing data into a GPKG file is, however, a bit complicated. The writer cannot be ignorant about geospatial, at least at two points.

SRID and WKT

gpkg_spatial_ref_sys table contains the information about the CRSs used by the layers. The specification says these columns are mandatory:

srs_id: Unique identifier for each Spatial Reference System within a GeoPackage
definition: Well-known Text Representation of the Spatial Reference System

So, at least, the writer needs to know the SRID and the WKT representation of the CRS of the data the writer is trying to write. This is not easy. In practice, this actually requires PROJ dependency if the writer want to support arbitrary SRIDs.

For comparison, take an example of GeoArrow's specification; GeoArrow allows various types of CRS. This is easy for writers. Of course, on the other hand, this imposes the responsibility of interpreting various CRS representation to the reader's side. But, the reader still be able to pass the CRS representation without interpreting. I think this is better strategy.

geoarrow.org

`ST_` Functions

A GPKG file includes spatial indices built on SQLite’s R-tree extension. The table definitions contain triggers that update the corresponding index. Here's an example:

CREATE TABLE IF NOT EXISTS "points"(
  "id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
  "geom" POINT,
  "name" TEXT,
  "elevation" REAL,
  "active" BOOLEAN,
  "category" TEXT,
  "note" TEXT
);
CREATE TRIGGER "rtree_points_geom_insert" AFTER INSERT ON "points" WHEN (new."geom" NOT NULL AND NOT ST_IsEmpty(NEW."geom")) BEGIN INSERT OR REPLACE INTO "rtree_points_geom" VALUES (NEW."id",ST_MinX(NEW."geom"), ST_MaxX(NEW."geom"),ST_MinY(NEW."geom"), ST_MaxY(NEW."geom")); END;
CREATE TRIGGER "rtree_points_geom_update6" AFTER UPDATE OF "geom" ON "points" WHEN OLD."id" = NEW."id" AND (NEW."geom" NOTNULL AND NOT ST_IsEmpty(NEW."geom")) AND (OLD."geom" NOTNULL AND NOT ST_IsEmpty(OLD."geom")) BEGIN UPDATE "rtree_points_geom" SET minx = ST_MinX(NEW."geom"), maxx = ST_MaxX(NEW."geom"),miny = ST_MinY(NEW."geom"), maxy = ST_MaxY(NEW."geom") WHERE id = NEW."id";END;
CREATE TRIGGER "rtree_points_geom_update7" AFTER UPDATE OF "geom" ON "points" WHEN OLD."id" = NEW."id" AND (NEW."geom" NOTNULL AND NOT ST_IsEmpty(NEW."geom")) AND (OLD."geom" ISNULL OR ST_IsEmpty(OLD."geom")) BEGIN INSERT INTO "rtree_points_geom" VALUES (NEW."id",ST_MinX(NEW."geom"), ST_MaxX(NEW."geom"),ST_MinY(NEW."geom"), ST_MaxY(NEW."geom")); END;
CREATE TRIGGER "rtree_points_geom_update2" AFTER UPDATE OF "geom" ON "points" WHEN OLD."id" = NEW."id" AND (NEW."geom" ISNULL OR ST_IsEmpty(NEW."geom")) BEGIN DELETE FROM "rtree_points_geom" WHERE id = OLD."id"; END;
CREATE TRIGGER "rtree_points_geom_update5" AFTER UPDATE ON "points" WHEN OLD."id" != NEW."id" AND (NEW."geom" NOTNULL AND NOT ST_IsEmpty(NEW."geom")) BEGIN DELETE FROM "rtree_points_geom" WHERE id = OLD."id"; INSERT OR REPLACE INTO "rtree_points_geom" VALUES (NEW."id",ST_MinX(NEW."geom"), ST_MaxX(NEW."geom"),ST_MinY(NEW."geom"), ST_MaxY(NEW."geom")); END;
CREATE TRIGGER "rtree_points_geom_update4" AFTER UPDATE ON "points" WHEN OLD."id" != NEW."id" AND (NEW."geom" ISNULL OR ST_IsEmpty(NEW."geom")) BEGIN DELETE FROM "rtree_points_geom" WHERE id IN (OLD."id", NEW."id"); END;
CREATE TRIGGER "rtree_points_geom_delete" AFTER DELETE ON "points" WHEN old."geom" NOT NULL BEGIN DELETE FROM "rtree_points_geom" WHERE id = OLD."id"; END;
CREATE TRIGGER "trigger_insert_feature_count_points" AFTER INSERT ON "points" BEGIN UPDATE gpkg_ogr_contents SET feature_count = feature_count + 1 WHERE lower(table_name) = lower('points'); END;
CREATE TRIGGER "trigger_delete_feature_count_points" AFTER DELETE ON "points" BEGIN UPDATE gpkg_ogr_contents SET feature_count = feature_count - 1 WHERE lower(table_name) = lower('points'); END;

If you scroll through the SQL definitions, you will notice several ST_ functions (e.g. ST_IsEmpty). You might assume these functions are automatically provided by SQLite.

Surprisingly, they are not. Just because they are used in the table definition does not mean they exist. We must provide the following functions ourselves:

ST_IsEmpty
ST_MinX
ST_MinY
ST_MaxX
ST_MaxY

This means the writer needs to parse WKB and iterate over coordinates. It is not extremely difficult, but it is an extra responsibility.

Writing an SQLite Database Actually Writes Multiple Files

If you have worked with a GPKG file, you may have noticed additional files such as .gpkg-wal and .gpkg-shm created when you open a .gpkg file. This adds complexity.

This even affects the API design of the SQLite library. The rusqlite's Connection::open() takes a Path, and there's no version that accepts impl std::io::Read.

pub fn open<P: AsRef<Path>>(path: P) -> Result<Self>

In other words, reading and writing an SQLite database requires a filesystem, not just a file handle. This is problem in web browsers, where a normal filesystem does not exist. In theory, sqlite-wasm-rs, the crate behind rusqlite's Wasm support, should support OPFS, but enabling it was not straightforward (sqlite_wasm_vfs::sahpool::install() is async while other APIs are sync).

Compared to other cloud-native formats that work as a single file, this feels like a disadvantage.

So, How Does It Feel?

Honestly, not very comfortable.

The need for geospatial logic in the writer and the requirement for a filesystem both make GPKG harder to use in modern, browser-based environments. Compared to other cloud-native formats available in 2026, it feels less flexible.

That said, GPKG still has clear strengths, especially for desktop use. And as SQLite is becoming cool again, I believe the ecosystem will improve (especially Turso)!

FOSS4G Auckland 2025

Hiroaki Yutani — Sat, 29 Nov 2025 10:53:36 +0000

Kia ora! Last week, we were in Auckland, New Zealand, for FOSS4G 2025. We had a great time and gave four talks about various topics from GTFS to GeoArrow. Thanks so much to the organizers for putting on such a fantastic conference, and to everyone who came to our presentations!

For those who missed the talks, no worries——we share the slides in this post below. You can click the image to jump to the slides.

As you know, the next global FOSS4G conference, FOSS4G 2026, will be held in Hiroshima, Japan (30 Aug - 5 Sep, 2026). We are looking forward to welcoming you, as part of the broader Japanese geospatial community!

DEV Community: Hiroaki Yutani

How it feels to write a GPKG library in 2026 (in Rust!)

yutannihilation / rusqlite-gpkg

GeoPackage reader/writer built on top of rusqlite.

rusqlite-gpkg

Web Demo

Overview

Browser usage (to_bytes / from_bytes)

The Age of LLMs

GPKG Is SQLite

Writer

SRID and WKT

`ST_` Functions

Writing an SQLite Database Actually Writes Multiple Files

So, How Does It Feel?

FOSS4G Auckland 2025

Make It Easier to View GTFS : Building a GTFS Timetable Viewer with SvelteKit (by Xinmiao Qu)

Implementing Longest Path Analysis in QGIS with NetworkX and Python (by Xinmiao Qu)

Interactive Simulation for Visualizing Bus Locations Using GTFS Data (by Kei Yamazaki)

GeoArrow on Web; Can We Live Without GeoJSON? (by Hiroaki Yutani)

DEV Community: Hiroaki Yutani

How it feels to write a GPKG library in 2026 (in Rust!)

yutannihilation / rusqlite-gpkg

GeoPackage reader/writer built on top of rusqlite.

rusqlite-gpkg

Web Demo

Overview

Browser usage (to_bytes / from_bytes)

The Age of LLMs

GPKG Is SQLite

Writer

SRID and WKT

ST_ Functions

Writing an SQLite Database Actually Writes Multiple Files

So, How Does It Feel?

FOSS4G Auckland 2025

Make It Easier to View GTFS : Building a GTFS Timetable Viewer with SvelteKit (by Xinmiao Qu)

Implementing Longest Path Analysis in QGIS with NetworkX and Python (by Xinmiao Qu)

Interactive Simulation for Visualizing Bus Locations Using GTFS Data (by Kei Yamazaki)

GeoArrow on Web; Can We Live Without GeoJSON? (by Hiroaki Yutani)

`ST_` Functions