GeoPackage vs Shapefile: A Developer's Migration Guide

The TL;DR

GeoPackage is technically superior to Shapefile on every meaningful axis. It is OGC-standardised, single-file, multi-layer, supports modern types, has no 2 GB ceiling, and is what every major GIS tool reads natively. If you're starting a new project today, default to GeoPackage.

Shapefile still wins when the recipient explicitly requires it. That's a real constraint and it covers a lot of ground — but it should be the only reason you reach for it.

Head-to-head

What GeoPackage gives you that Shapefile can't

One file. A .gpkg is one file. Email it, upload it, version-control it (LFS), unzip it nowhere. No more "where's the .prj?" support tickets.

Multiple layers. A single GeoPackage can carry a parcel layer, a roads layer, a points-of-interest layer, and a raster basemap. Shipping a multi-theme dataset becomes one attachment instead of a ZIP of folders.

Honest types. GeoPackage uses SQLite's column type system. NULL is NULL, true is a boolean, timestamps carry their hour and minute, and a 64-bit ID column actually holds 64-bit IDs. Shapefile coerces all of these into strings or sentinel values.

Spatial index built in. Every GeoPackage layer can have an R-tree (rtree_<table>_<geom>) for fast bounding-box queries. Shapefile's index is optional, external, and tool-specific.

Storable as a database. You can open a GeoPackage with the SQLite CLI, run regular SQL on it, add views, write triggers. It's a real database masquerading as a file.

The migration recipe

For most cases, this is a one-liner:

ogr2ogr -f GPKG out.gpkg in.shp

If you have several Shapefiles to bundle into one GeoPackage:

for f in *.shp; do
  layer="$(basename "$f" .shp)"
  ogr2ogr -f GPKG -update -append out.gpkg "$f" -nln "$layer"
done

If the Shapefile's .prj is missing, declare the source CRS explicitly:

ogr2ogr -f GPKG -s_srs EPSG:25833 -t_srs EPSG:4326 out.gpkg in.shp

QGIS does the same: right-click the layer → Export → Save Features As → Format GeoPackage.

What you'll notice after migrating

• Field names get longer. If the Shapefile had population and populatio_ (truncated from population_male and population_female in the original DB), the GeoPackage preserves whatever names ogr2ogr derives — sometimes you need to rename manually.
• Empty strings become NULLs. Shapefile's empty-string-as-missing convention gets normalised. Downstream code that checks for empty strings needs to check for NULL too.
• Date columns may shift type. Some converters write date as text. Inspect with PRAGMA table_info and ALTER COLUMN if you need a true date type.

When Shapefile still wins

There are honest reasons to stick with Shapefile:

1. Government procurement. Public-sector RFPs from 2005–2015 still specify Shapefile as the deliverable. Read the spec; if it says Shapefile, ship Shapefile.
2. Legacy desktop users. A surveyor on ArcMap 9.3 or AutoCAD Map 2014 may not have a GeoPackage driver. If the recipient won't budge, neither can you.
3. Mobile field tools. A few field-collection apps still read Shapefile better than GeoPackage. Confirm before migrating.
4. The 100-byte case. For a single point with three attributes, Shapefile's overhead is lower than GeoPackage's SQLite scaffolding. This matters never in practice but I'll mention it once.

In every other case in 2025, GeoPackage is the right default.

A note on the OGC stamp

GeoPackage is an OGC standard (OGC 12-128r19). That matters because procurement language can specify "OGC-compliant vector exchange format" — and GeoPackage qualifies while Shapefile does not. If you're writing the procurement spec, this is the magic phrase.

The migration question

If you're a single-person shop or a small team: migrate. The tooling is identical, the format is better, your future self will thank you. If you're in a 50-person GIS department with established workflows and downstream consumers: pilot it on one new project before changing defaults. The transition cost is real, but the destination is right.