What Is a GeoPackage?

A GeoPackage is a portable SQLite database file that follows the Open Geospatial Consortium's GeoPackage standard. It can store vector features, non-spatial attributes, tiled imagery or raster maps, coordinate-reference-system information, and extensions inside one .gpkg file.

That makes it very different from a shapefile, which represents one vector layer using several companion files; a GeoPackage is instead a database container that can hold several geospatial tables and related content together.

The current OGC GeoPackage Encoding Standard is version 1.4.0.

A GeoPackage is a database, not just a wrapper

SQLite is a relational database engine stored in a single file, and GeoPackage defines tables, metadata conventions, geometry encoding, spatial-reference-system records, and other requirements on top of it.

Because the file is a real database, software can query or update data directly without unpacking an archive or translating every feature into another intermediate representation.

A single GeoPackage can contain, for example:

a polygon layer of administrative boundaries;
a point layer of facilities;
ordinary lookup tables;
multiple coordinate reference system records;
tile matrix sets;
indexes and extension tables where supported.

That makes it useful for project exchange and offline work where several related layers need to travel together.

Why one file matters

A one-file container reduces several practical failure modes.

You do not need to remember to copy a .shp, .shx, .dbf, and .prj together; field names and data types are not constrained by the old dBASE attribute model; and multiple layers can remain in one coherent package.

This does not mean a GeoPackage is immune to bad metadata or poor data modelling. It means the format provides a stronger container for preserving those relationships.

Vector features remain tabular

A GeoPackage feature table stores ordinary attributes plus a geometry column. Metadata records identify the geometry type, CRS, and table role.

Because the underlying system is SQL-based, the format can support richer schemas than shapefile while remaining portable across many desktop and mobile GIS tools. Spatial indexes can also be represented through the standard's RTree extension, allowing software to accelerate spatial filtering without scanning every feature.

GeoPackage can store raster tiles too

The standard is not limited to vector features; it can also store tile matrix sets of imagery or raster maps at multiple scales.

That capability should not be confused with GeoTIFF. A GeoTIFF stores georeferenced raster imagery in TIFF form. A GeoPackage tile table stores pre-tiled map or imagery content in a database structure.

For raw analytical rasters, elevation surfaces, or satellite imagery, GeoTIFF or Cloud Optimized GeoTIFF may be more natural. For a portable project package containing vector data and prepared map tiles, GeoPackage can be convenient.

Extensions add capability—with an interoperability trade-off

GeoPackage defines a formal extension mechanism. Extensions can add features beyond the core standard while documenting the additional tables or behaviour required.

That flexibility is useful, although it creates an important distinction:

a GeoPackage using only widely implemented standard capabilities is broadly interoperable;
a GeoPackage depending on a specialised extension may require software that understands that extension.

“Stored in a .gpkg file” therefore does not guarantee that every GeoPackage-aware tool can interpret every possible extension equally.

When GeoPackage is a strong choice

GeoPackage works well for:

exchanging several related GIS layers in one file;
offline desktop or mobile GIS;
replacing shapefile in workflows that need better schemas and fewer companion files;
project deliverables that should remain editable rather than only rendered;
datasets whose size and access pattern fit a local SQLite database.

It is less naturally suited to massive distributed analytical tables where columnar formats such as GeoParquet provide better scan efficiency, or to browser delivery where GeoJSON or vector tiles may integrate more directly with web clients.

One format does not have to serve every stage

A useful workflow may keep editable vector data in GeoPackage, run large analytical processing in GeoParquet or a spatial database, and publish web-optimised vector tiles. In other words, the best format is often determined by the job at that stage rather than by a desire to use one file type everywhere.

References

OGC GeoPackage Standard. Describes GeoPackage as an open, SQLite-based container for vector features, tile matrix sets, attributes, and extensions.
OGC GeoPackage Encoding Standard 1.4.0. Current approved encoding specification and schema requirements.