Learn

GeoPackage vs Shapefile

Compare GeoPackage and Shapefile by structure, attributes, coordinate systems, portability, compatibility, and editing workflows to decide which format fits your GIS data.

Geobble
introductoryexplainerGIS File Formats

Help readers decide between GeoPackage and Shapefile without reducing the comparison to old versus new, explaining where GeoPackage's database model provides real advantages and where Shapefile's unusually broad compatibility still matters.

GeoPackage vs Shapefile

If you control both ends of a modern GIS workflow, GeoPackage is usually a better general-purpose format than Shapefile. It can store multiple layers in one file, uses a richer database-backed attribute model, keeps coordinate reference system information inside the container, supports transactions, and avoids several long-standing Shapefile limitations.

Shapefile still has one important advantage: extraordinary compatibility. It has been supported across GIS software for decades, and some organisations, data portals, scripts, and legacy systems still explicitly require it.

The choice is therefore not simply “modern format good, old format bad”. It is a trade-off between a richer portable GIS container and a simpler legacy format whose constraints are widely understood.

The difference at a glance

  • Column 1: Structure; GeoPackage: One SQLite database file; Shapefile: Several companion files

  • Column 1: Typical extension; GeoPackage: .gpkg; Shapefile: .shp + .shx + .dbf, often .prj and others

  • Column 1: Multiple vector layers in one dataset; GeoPackage: Yes; Shapefile: No

  • Column 1: Attribute storage; GeoPackage: SQLite tables; Shapefile: dBASE / DBF

  • Column 1: Field names longer than 10 characters; GeoPackage: Yes; Shapefile: Conventionally no

  • Column 1: Null values; GeoPackage: Supported; Shapefile: Poor/limited support

  • Column 1: Unicode text; GeoPackage: Supported through SQLite; Shapefile: Historically problematic and encoding-dependent

  • Column 1: CRS information; GeoPackage: Stored within the GeoPackage; Shapefile: Commonly stored separately in .prj

  • Column 1: Transactions; GeoPackage: Yes; Shapefile: No database transaction model

  • Column 1: Spatial indexes; GeoPackage: Supported; Shapefile: Optional sidecar indexes

  • Column 1: Raster/tile content; GeoPackage: Supported by the standard; Shapefile: No

  • Column 1: Direct SQL access; GeoPackage: Yes; Shapefile: No

  • Column 1: Legacy GIS compatibility; GeoPackage: Broad; Shapefile: Exceptionally broad

  • Column 1: Best fit; GeoPackage: Portable modern GIS datasets; Shapefile: Simple interchange with legacy or explicitly Shapefile-based systems

GeoPackage 1.4.0 is the current adopted OGC standard. It defines a GeoPackage as a SQLite database container capable of storing vector features, tile matrix sets, attributes, and extensions, while remaining directly usable rather than requiring extraction into another format first.

Shapefile takes a much simpler approach. Geometry, indexing, and attributes are divided between separate files, and the attribute table inherits limitations from its DBF representation. Esri still describes Shapefile as useful for simple feature exchange, while explicitly warning that it is a poor fit for active database management and richer modern attributes.

The biggest difference is the storage model

A Shapefile represents one feature layer through a family of files.

For example:

roads.shp
roads.shx
roads.dbf
roads.prj
roads.cpg

The .shp contains geometry, .shx indexes the geometry, .dbf contains attributes, and additional files can carry information such as the CRS and text encoding.

That architecture is explained in more detail in Why Is a Shapefile Made of Multiple Files?.

GeoPackage instead uses SQLite.

A file such as:

transport.gpkg

can contain several feature tables:

roads
bus_stops
railways
administrative_boundaries

alongside the tables required to describe their coordinate reference systems and other GeoPackage metadata.

The GeoPackage standard specifically allows one container to hold one or many vector feature datasets and other supported content. Because SQLite is a relational database, the file is also self-contained, serverless, cross-platform, and transactional.

This changes what the file represents.

A Shapefile is essentially one vector layer.

A GeoPackage can behave more like a small portable geographic database.

GeoPackage avoids many Shapefile attribute limitations

For simple attributes such as:

name
population
category

both formats can work perfectly well.

Differences become more visible as the schema becomes richer.

Shapefile attributes are stored using DBF, and that brings constraints inherited from an older data model. Current ArcGIS documentation notes, among other limitations, that Shapefiles do not support null values well, limit field names to ten characters, have weak Unicode support, and cannot store time within a date field.

A field such as:

population_estimate_2025

therefore cannot remain that name in a conventional Shapefile schema. It must be shortened.

This can become more than a cosmetic inconvenience when several meaningful field names collapse into abbreviations such as:

POP_EST25
POP_DEN25
POP_PROJ25

Anyone receiving the dataset now needs additional context to understand the schema.

GeoPackage feature tables use SQLite columns instead. The OGC standard defines types including integer, real, text, blob, boolean, date, and datetime representations, and feature attributes appear as ordinary columns beside the geometry.

That provides considerably more room for maintaining a clear and expressive data model.

Null is not the same as zero

The attribute-model difference has a particularly important consequence: missing values.

Suppose a dataset contains a field:

hospital_beds

For one facility:

hospital_beds = 0

might mean the facility genuinely has no beds.

For another:

hospital_beds = NULL

might mean the number is unknown.

Those statements are not equivalent.

Esri's documentation specifically identifies the inability to store null values as one of Shapefile's weaknesses. Depending on field type and software behaviour, a missing value may need another representation, making it easier to blur the distinction between unknown, empty, and genuine zero values.

GeoPackage, through SQLite, can preserve null values directly.

For datasets in which missingness has meaning, this is a substantive data-quality advantage rather than merely a modern convenience.

CRS information travels differently

A Shapefile commonly stores coordinate reference system information in a companion .prj file.

That means it is possible to copy:

boundaries.shp
boundaries.shx
boundaries.dbf

and accidentally leave:

boundaries.prj

behind.

The geometries and attributes still exist, but the recipient may no longer know how the coordinate values should be interpreted.

GeoPackage stores spatial reference system definitions inside the database. The standard requires a gpkg_spatial_ref_sys table, and feature tables reference the appropriate spatial reference system through the GeoPackage schema.

That does not guarantee that the CRS information is correct—bad metadata can exist in any format—but it removes one common failure mode: separating the geographic data from its CRS sidecar during ordinary file transfer.

If CRS metadata is already missing or wrong, changing formats does not magically repair it. Assigning the correct CRS and reprojecting coordinates remain separate operations.

Multiple layers are where GeoPackage becomes especially useful

Suppose you need to send five related layers:

  • administrative boundaries;

  • health facilities;

  • schools;

  • roads;

  • rivers.

With Shapefile, that might result in at least:

admin.shp
admin.shx
admin.dbf
admin.prj

health.shp
health.shx
health.dbf
health.prj

schools.shp
schools.shx
schools.dbf
schools.prj

roads.shp
roads.shx
roads.dbf
roads.prj

rivers.shp
rivers.shx
rivers.dbf
rivers.prj

before optional encoding, index, or metadata files are considered.

A ZIP archive makes distribution manageable, but the contents are still five independent Shapefiles.

A GeoPackage can instead contain those five vector datasets inside:

regional_data.gpkg

That can be particularly valuable when the layers conceptually belong together and should travel as a unit.

It also means that adding another layer does not require creating another family of sidecar files.

GeoPackage can contain more than vector features

Shapefile is fundamentally a vector-feature format.

GeoPackage's standardised scope is broader. The OGC specification supports:

  • vector feature tables;

  • non-spatial attribute data;

  • tile matrix sets for imagery and raster maps;

  • extensions for additional capabilities.

This does not mean that every piece of GIS content should be packed into one GeoPackage, or that it is a substitute for every specialised raster or database format.

It means that the container has a broader model than Shapefile.

If a workflow genuinely benefits from distributing several related kinds of geospatial information together, that flexibility can matter.

GeoPackage is a real database—but a small local one

Because a GeoPackage is SQLite, applications can access its tables using SQL.

That can make inspection, filtering, indexing, and structured data management more capable than treating a dataset as a collection of flat files.

The format also inherits database transactions. The GeoPackage standard describes SQLite as transactional, meaning groups of changes can maintain atomicity and consistency even if an operation fails partway through. GDAL likewise supports dataset-level transactions for its GeoPackage driver.

But this distinction should not be exaggerated.

A GeoPackage is not equivalent to a database server such as PostgreSQL/PostGIS.

It is designed around a portable, local, single-file SQLite database. That makes it excellent for desktop, field, mobile, offline, and interchange workflows, but it does not give it the same multi-user architecture, server-side access control, concurrency model, or operational role as a full spatial database server.

So the useful progression is not:

Shapefile → GeoPackage → therefore database problem solved.

It is closer to:

Shapefile → simple flat-file vector exchange

GeoPackage → portable database-backed geographic container

PostGIS → server-based spatial database for workflows that need that architecture

Spatial indexes are easier to keep with the dataset

Both formats can use spatial indexes.

With Shapefile, indexes such as .sbn, .sbx, or .qix appear as additional companion files. They can improve geographic queries, but they add more physical components around the dataset.

GeoPackage has a standard RTree spatial-index extension. Because the index lives inside the SQLite container, it travels with the .gpkg rather than appearing as another external sidecar. The OGC specification specifically recommends RTree spatial indexes for GeoPackages containing non-trivial amounts of vector data.

Again, this is less about a checkbox saying “GeoPackage has indexes” and more about the storage model.

Related structures can remain part of one database file.

Is GeoPackage always smaller or faster?

No.

It is tempting to infer from the more modern design that a GeoPackage will always produce a smaller file or make every operation faster.

That is not a safe generalisation.

Performance depends on factors such as:

  • number of features;

  • geometry complexity;

  • attribute width;

  • indexes;

  • how the application reads the data;

  • transaction strategy;

  • SQLite settings;

  • what operation is being performed.

A Shapefile containing a simple layer can be extremely straightforward and fast to read. A poorly indexed or unusually structured GeoPackage can perform badly for a particular operation.

Likewise, file size depends on the actual data and how it is stored.

The stronger reasons to prefer GeoPackage are its data model, self-contained structure, standards-based database container, and reduced need to discard or reshape information—not an unsupported claim that .gpkg is always smaller or faster.

What does Shapefile still do better?

Its biggest advantage is compatibility.

Shapefile has existed for decades and is understood by an enormous range of GIS software. It is still commonly encountered in government data portals, environmental datasets, planning workflows, research exchanges, and older organisational systems.

That makes Shapefile a perfectly rational output when:

  • a recipient explicitly requests it;

  • an existing tool accepts only Shapefile;

  • a public-data submission specification requires it;

  • you are exchanging a simple layer with unknown or older GIS software;

  • preserving sophisticated attributes is not important.

Esri itself still lists simple feature export and interoperability with non-Esri software among situations where Shapefile can be useful, despite recommending geodatabase-based formats for richer data management.

Compatibility is a real capability.

A technically richer file that the receiving system cannot open is not automatically the better interchange format.

When should you migrate a Shapefile to GeoPackage?

Moving to GeoPackage makes particular sense when Shapefile's constraints are beginning to influence the data.

For example:

Your field names are being truncated. GeoPackage removes the ten-character Shapefile naming constraint.

Null values matter. A database-backed model gives you a cleaner distinction between missing values and real values such as zero.

You have several related layers. They can travel in one container instead of many Shapefile sets.

You repeatedly lose companion files. Geometry, attributes, CRS definitions, and internal structures remain within the GeoPackage.

You need richer text handling. SQLite provides a substantially better foundation for modern text than DBF-era encoding conventions.

The file is actively edited rather than merely exchanged once. Transactions and the database structure make GeoPackage more appropriate for ongoing local data management.

You want a modern open standard without requiring a database server. This is one of GeoPackage's strongest niches.

The broad format-selection article, GeoJSON vs Shapefile vs GeoPackage vs KML, places that choice alongside web-oriented and presentation-oriented alternatives.

When should you keep using Shapefile?

There are also cases where conversion produces little practical benefit.

Suppose you have:

  • one simple polygon layer;

  • six short attribute fields;

  • no null values;

  • ordinary text;

  • a correct .prj;

  • a recipient whose workflow explicitly expects Shapefile.

Converting it to GeoPackage solely because GeoPackage is newer may solve no actual problem.

The decision becomes more compelling when Shapefile's limitations are already forcing compromises.

This suggests a more useful rule than “never use Shapefile”:

Do not choose Shapefile by default when its constraints are unnecessary, but do not reject it when compatibility is itself a genuine requirement.

Conversion deserves a check afterwards

Moving from Shapefile to GeoPackage is often straightforward, but conversion should still be verified.

Check:

  • feature count;

  • geometry type;

  • CRS;

  • extent;

  • attribute names;

  • data types;

  • null values;

  • text encoding;

  • identifiers;

  • geometry validity.

If the Shapefile has already lost information—for example because field names were truncated before you received it—putting the data into a GeoPackage cannot reconstruct the original names automatically.

Likewise, if the .prj is missing and the true source CRS is unknown, conversion does not solve the underlying reference-system problem.

A new format can preserve information better going forward.

It cannot manufacture information that has already been discarded.

That broader issue is why format conversion should be treated as a data transformation rather than just changing a filename.

GeoPackage is usually the better default, not the universal winner

For new GIS workflows where you need a portable vector format and control the tools on both sides, GeoPackage has substantial advantages over Shapefile.

One file can contain several layers. Attributes are not constrained by the DBF model. CRS definitions stay inside the container. SQLite provides transactions and SQL access. The format can accommodate a broader range of geospatial content while remaining open and standardised.

Shapefile's design is considerably more limited.

But its longevity produced something difficult for a newer format to reproduce instantly: a vast compatibility footprint.

So the practical conclusion is:

Use GeoPackage as a strong default for modern portable GIS data when the receiving software supports it.

Use Shapefile when compatibility, an external requirement, or a legacy workflow genuinely makes it the appropriate boundary format.

The important part is that the choice should be deliberate.

Shapefile should not survive in a workflow merely because it is the format everyone selected twenty years ago, and GeoPackage should not replace it merely because .gpkg looks more modern.

Choose the format whose structure preserves the information your next step actually needs.

References

  1. Open Geospatial Consortium — GeoPackage Standard. Describes GeoPackage as an open, standards-based SQLite container for vector features, tile matrix sets, attributes, and extensions; current adopted version: 1.4.0.

  2. OGC GeoPackage Encoding Standard 1.4.0. Defines the SQLite container, feature tables, spatial-reference-system tables, geometry model, attribute types, and other GeoPackage requirements.

  3. Esri ArcGIS Pro — Geoprocessing Considerations for Shapefile Output. Documents current Shapefile strengths and limitations, including field-name length, null handling, Unicode, date/time representation, and suitability for simple interchange rather than active database management.

  4. GDAL — GeoPackage Vector Driver. Documents practical GeoPackage support including database-level transactions and related-table capabilities.