What is the difference between a file geodatabase and a GeoPackage?

A file geodatabase is Esri's proprietary .gdb folder of binary files, optimised for ArcGIS with topology, domains, and networks. A GeoPackage is an open OGC standard: a single SQLite .gpkg file holding multiple vector and raster layers, readable by virtually all modern GIS.

Is GeoPackage an open standard?

Yes. GeoPackage is an OGC standard (a defined SQLite/SQL profile). Its specification is public, so any software can implement full read/write support without a proprietary SDK.

Can QGIS read a file geodatabase?

QGIS can read file geodatabases through GDAL's OpenFileGDB driver, including raster in recent GDAL versions. Write support is limited; for portable editing, convert to GeoPackage with ogr2ogr or export from ArcGIS.

When should I use a file geodatabase instead of a GeoPackage?

Use a file geodatabase when you are inside the Esri ecosystem and need its features: geodatabase topology, domains and subtypes, relationship classes, networks, or attribute/archive features ArcGIS expects. Otherwise GeoPackage is the more portable default.

Geodatabase vs GeoPackage: Which to Use

Short answer

A file geodatabase (.gdb) is Esri's proprietary container — actually a folder of binary files — built for ArcGIS and rich with Esri-specific capabilities: geodatabase topology, attribute domains and subtypes, relationship classes, networks, and archiving. A GeoPackage (.gpkg) is an open OGC standard: a single SQLite database file that can hold many vector layers, raster tiles, attributes, and metadata, and that virtually every modern GIS reads and writes natively.

The practical rule: if your project lives inside the Esri ecosystem and needs geodatabase topology, domains, or networks, use a file geodatabase. For everything else — cross-software exchange, a portable multi-layer project, client delivery, long-term archive — the GeoPackage is the safer default because it is one open file with no proprietary SDK between you and your data.

What each format actually is

File geodatabase — a folder, not a file

A .gdb is a directory containing dozens of binary .gdbtable, .gdbtablx, .atx, and index files. You never touch them individually; ArcGIS treats the folder as one database. Within it you can store feature classes, feature datasets (groups sharing a CRS, used for topology and networks), raster datasets and mosaic datasets, tables, attribute domains (coded/ranged value constraints), subtypes, and relationship classes (formal one-to-many links between tables). It supports geodatabase topology rules enforced across feature classes — invaluable for geological mapping where unit polygons must not gap or overlap and contacts must coincide with polygon boundaries.

The format is proprietary. Esri publishes an open File Geodatabase API, and GDAL's OpenFileGDB driver gives broad open read support (and increasingly write), but the richest behaviour — topology validation, domain enforcement, networks — is realised inside ArcGIS. The older personal geodatabase (.mdb, Access-based) is deprecated; "geodatabase" today means file or enterprise.

GeoPackage — one SQLite file, fully specified

A .gpkg is a single SQLite 3 file conforming to the OGC GeoPackage standard. The spec defines required system tables: gpkg_spatial_ref_sys (CRS definitions), gpkg_contents (the catalogue of layers), and gpkg_geometry_columns, plus the geometry encoding (a small binary header followed by WKB). Because the standard is public, software implements it directly — no Esri SDK required. One .gpkg can carry multiple vector layers, raster/tile pyramids, attribute-only tables, and metadata, all in that single file. Geometries are stored with an explicit SRS ID per layer, and spatial indexing uses SQLite's R-tree.

Two SQLite consequences matter operationally: a GeoPackage is a real database you can query with SQL, but it is single-writer — SQLite locks the whole file during a write, so it is not a substitute for a multi-user server database like PostGIS.

Head-to-head on the things that bite

Openness: GeoPackage is an OGC standard, fully documented; file geodatabase is proprietary with partial open tooling.
Single file vs folder: .gpkg is one file (easy to email, copy, version-name); .gdb is a folder that must be zipped to transfer and breaks if partially copied.
Multi-software support: GeoPackage reads/writes everywhere (QGIS, GDAL, ArcGIS, R, Python); file geodatabase writes best in ArcGIS, reads broadly via GDAL.
Size limits: a file geodatabase scales to very large datasets (terabytes; default 1 TB per dataset, raisable) and historically outperformed shapefiles dramatically. GeoPackage (SQLite) supports very large files too (SQLite's theoretical limit is ~281 TB), but practical single-writer performance and the lack of native enterprise features cap heavy concurrent use.
Advanced data model: topology, domains, subtypes, relationship classes, networks — file geodatabase has them natively; GeoPackage models these with plain tables/constraints or you push them to PostGIS.
Field-name/length limits: neither suffers the shapefile's 10-character field-name and 254-character text limits, so both are large upgrades over shapefile for attribute-rich geology.

Raster, performance, and the SQLite reality

Both formats hold raster as well as vector. A file geodatabase stores raster datasets and mosaic datasets that ArcGIS manages efficiently at large scale. GeoPackage stores raster as tiled pyramids (gpkg_tile_matrix), which is well suited to pre-rendered map tiles and overviews but is not a general-purpose analytical raster container — for heavy raster analysis most people keep elevation and imagery as GeoTIFF/COG and reference them, putting only vector and tile data in the .gpkg.

On performance, the honest summary is that both vastly outperform shapefiles and both are fine for typical project sizes (tens of thousands to low millions of features). The file geodatabase has a long track record at very large dataset sizes inside ArcGIS, with mature spatial indexing. GeoPackage performance depends on SQLite: an R-tree spatial index (gpkg_rtree_index) makes spatial queries fast, but the single-writer lock means it does not scale to concurrent editing. A useful mental model: GeoPackage is a brilliant transport and single-user working container; for genuine multi-user, transactional, server-side work you graduate to PostGIS, which shares much of the same SQL vocabulary (ST_Transform, ST_Intersects) so the conceptual jump is small.

Worked example: converting and packaging

You receive a project.gdb with three feature classes (units, faults, stations) and need a portable, single-file deliverable.

Inspect it first:

ogrinfo project.gdb           # lists the feature classes (layers)
ogrinfo -al -so project.gdb units   # schema + CRS for one layer

Convert all layers into one GeoPackage:

ogr2ogr -f GPKG project.gpkg project.gdb        # copies every layer
# or layer by layer to control names/CRS:
ogr2ogr -f GPKG project.gpkg project.gdb units -nln geo_units -t_srs EPSG:32632
ogr2ogr -f GPKG -append project.gpkg project.gdb faults -nln geo_faults
ogr2ogr -f GPKG -append project.gpkg project.gdb stations -nln field_stations

Going the other way (GeoPackage to file geodatabase) is best done in ArcGIS (Feature Class to Feature Class / Export), because the rich write path lives there. After any conversion, verify the result:

ogrinfo -al -so project.gpkg   # confirm layer count, geometry types, CRS, field names

In QGIS you can do the same via Export → Save Features As → GeoPackage, but for repeatable delivery the ogr2ogr line is auditable and re-runnable.

Common pitfalls and why they happen

Copying a .gdb as if it were a file. Copying only some of the internal files corrupts the geodatabase; it must be moved/zipped as a whole folder. Zip the directory.
Expecting topology/domains to survive export. Converting .gdb → .gpkg keeps geometry and attributes but drops Esri-specific topology rules, domains, subtypes, and relationship classes; they are enforced by ArcGIS, not by the bytes. Document or re-create constraints in the target system.
Treating GeoPackage like a multi-user database. SQLite's whole-file write lock means concurrent editors collide. For multi-editor work use PostGIS, not a shared .gpkg.
Field-name / encoding drift on conversion. Reserved names, casing, or non-UTF-8 text can change during conversion. Check schema and encoding after ogr2ogr.
Assuming "export succeeded" means "data is clean." A successful write does not validate geometry or CRS. Run ogrinfo / geometry checks afterwards.

QA before you trust the output

Confirm layer count, geometry types, and CRS match the source (ogrinfo -al -so).
Validate geometry (no self-intersections, correct winding) and attribute schema (field names, types, encoding) after conversion.
Check that coordinate order and CRS are correct by spot-checking a known feature against a reference layer.
For deliverables, include a short metadata/README noting source, CRS, schema, date, and any constraints that did not transfer.
Verify the recipient's software can both open and maintain the format, not just preview it.

Bathyl perspective

We default to GeoPackage for delivery and archive because a single open SQLite file survives handoff between QGIS, ArcGIS, Python, and a client's archive without a proprietary dependency. We keep a file geodatabase only when an Esri-specific feature — geodatabase topology, domains, or networks — is genuinely required, and we record in the delivery notes exactly which constraints live in the format versus which are enforced by the software.

File Geodatabase vs GeoPackage