Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am a bit confused on the topic of geodatabases. Previously, I have used geodatabases as an easy way to keep all files together rather than having dozens of shapefiles all over the place. And it's easier when finally exporting all the relevant stuff to the client.

But earlier it got me thinking; what is really the difference between gdb's and mdb's, from a user's perspective? Which one should I stick to? Why should I use a geodatabase (should I?) instead of shapefiles when analysing and running functions on my data? Pros and cons in general?

My primary focus is within ArcGIS, I don't usually edit stuff outside of that environment.

This question is somewhat related to How does Personal Geodatabase work from Microsoft Access perspective?, but it was asked quite a while ago and references mainly ArcMap 9.3.


locked by PolyGeo Dec 20 '15 at 21:52

This question's answers are a collaborative effort: if you see something that can be improved, just edit the answer to improve it! No additional answers can be added here

If sharing data outside of ESRI environment then Shapefile - If not then File Geodatabase are the way to go (larger databases can be handled) – Mapperz May 8 '13 at 13:37
You can always keep data in a geodb, and export to Shapefile when you have to share outside of an Esri environment. – user3461 May 9 '13 at 12:06
I believe geodatabases are useful, as most have pointed out. Although shapefiles are probably easier to handle since they can be used with so many programs. – SteveJ Jul 24 '13 at 9:01
up vote 48 down vote accepted

At a high level, the way I choose is based on whether users are inexperienced and need nothing more than points, lines and polygons. Shapefiles are ideal for this.

If they need annotation, domains for pick lists and validation, raster, longer field names, etc then use File Geodatabases which are easy to use, fast and can be massive in size.

I would never use Personal Geodatabases based on MS Access unless there is a requirement for Access users to also interact with them. I find their 2Gb size limit & inability to store rasters restrictive.

Agreed, never use personal GeoDatabase's. They are limited in functionality and size. File GeoDatabase's or Shapefile's are the way to go. And only use Shapefile's when you need to deliver a product to someone in that format. Otherwise FGDB is the best ESRI way to store spatial data. – Cody Brown May 8 '13 at 13:48
One of the big cons for shapefiles that I can see, especially if working in a multi-user editing environment, is that you wind up having several different versions of shapefile data laying around and lose control of the data. – Craig May 8 '13 at 14:33
In talking with ESRI folks it is my understanding that they would like to phaseout personal geodatabases (mdb). – Jeffrey Evans May 8 '13 at 16:23
"Never use personal geodatabases" does a disservice, I think. It's not just reaching the data through Access, it's reaching the data through anything else that has ODBC access or drivers for using Access as a database backend. That opens up huge possibilities for serverless, spatial relational databases in ArcGIS. ESRI can do away with the mdb ones, but I think they now have personal geodatabases built into SQL Server Express, so you can do something similar. Generally, I think FGDBs are the way to go, but in the environments I work in, personal GDBs often have more utility than shapefiles. – nicksan May 15 '13 at 13:52
It is important to note that the 2GB limitation is the only disadvantage of PGDB while on the other hand FGDB is very limited in SQL querying capabilities. PGDB allows users to take advantage of the full underlying RDBMS while File Geodatabase is very simplistic. Fundamental keywords such as "DISTINCT" or "ORDER BY" do not work with File Geodatabases. ESRI has been promising to add this functionality since FGDB conception but it is still not available. – Jakub May 15 '13 at 14:26

I try to avoid using shapefiles as you cannot store domains, relationships, aliases etc. but they are the most portable format when distributing data to other people who are using different GIS systems/tools.

Whilst file geodatabases give better performance and are capable of storing huge datasets, everyone above is giving the humble personal geodatabase a bad rap. I use them to store my analysis as you can use ODBC to suck the attribute data right out of them into your preferred statistical application. If your data is in a File GeoDatabase you have to mess around with converting them into some staging format before you can use them as nothing else can read from a File GeoDatabase (unless you want to spent time and effort programming the API...).

So for projects I adopt both formats, file geodatabase for large static datasets, personal geodatabases for outputs and analysis (unless the outputs are huge then they go into a file geodatabase).

If you are working on a project that has small datasets and everything sits happily inside a personal geodatabase then it's just 1 file to zip up and email. Something to consider?

Fully agree. For small project, specially research project, 2 G is quite sufficient. Ability to directly manipulate attribute table with statistical software make analysis so much easier. – anh.hv May 15 '13 at 5:20
Using ODBC is a big plus, but I will say that it's becoming easier to find ways of working with File GDBs programmatically. For example, in both .NET and Python, you can use GDAL with the ESRI FileGDB API to read your data. Would be nice if there were an ODBC driver for them, though. – jpmc26 Mar 25 '14 at 5:12

File geodatabases (FGDB):

  • A FGDB may contain feature datasets, which aid in coordinate system control and data integrity via topology rules. You are on your own with shapefiles.
  • FC's may be up to 256 TB in size with the use of configuration keywords. All component files of a shapefile are limited to 2GB each (source & whitepaper).
  • FC performance is quite simply faster than shapefile, especially in operations involving attributes.
  • Vector data can be used in a compressed read-only format which can greatly reduce the file size.
  • FC's are used in map packages which are a handy way of sharing data.

Personal Geodatabases (PGDB):

  • Often used as an attribute table manager (via Microsoft Access).
  • Users like the string handling for text attributes.


  • Greater usability cross-platform (e.g. QGIS, ArcGIS) and for geospatial operations in a non-ESRI scripting environment (e.g. pure Python, R, Matlab).
  • Many end-users get irritated if you send them a FGDB rather than a zipped folder containing shapefiles. As a side note, KML files are often used over SHP files or FGDB's to share simple spatial data.
  • Shapefiles are easier to sync to the cloud using a service such as Google Drive, whereas FC's & FGDB's often have sync errors.
Great answer! For completeness, what is your take on PGDB's (.mdb)? – Martin Jan 7 '14 at 7:17

Most people would recommend storing your data in a database for performance reasons, i.e quick to query and search. However I believe there is also the benefit of currency when data is in a database. For example, if you pass a shapefile to a colleague they are likely to use that indefinitely but the data may have been updated. Where as if the data was stored in a database and the user connected to that database using ArcGIS then they would always see the most current and up-to-date data.

So the main Pros of a database are Performance Querying Indexing (although you can index in a FileGDB and MDB or even have a shapefile index however I have found that you can give a database more RAM when indexing, so I put this down as a Pro to the database) Spatial Functions run quicker in a database If you have text or addresses you can have Full Text Search

Cons Knowledge - affects both Proprietary or Open Source Dedicated Server in productions Costs - setup and running

FileGDB/MDB Pros Portable Plug and Play (almost as simple as shapefiles) Can be compressed to reduce size

Cons Can take a long time to create (my personal experience) for a lot of data ESRI Restricted(ish) Concurrent Users File limits

MDB is an microsoft access backed geodatabase which ends up having a file limit of 2Gb so if you have more data or want to provide more access to other uses then use a FileGDB.

More differences can be seen here

Hope that gives you some idea


I generally use FGDBs, but it really depends on what you need to store. Like the other posts have mentioned, Personal GDBs are outdated and have size issues.

Using a geodatabase allows you to set up a topology, which you can't do with plain shapefiles.

Shapefiles hold the exact coordinates of the shapes. In a GDB, the locations are snapped to the nearest point on a grid. I've not run into problems with this, it can cause small changes in data. Also, Shapefiles are easier to access with 3rd party tools. ESRI has an API for the FGDB, but it's new compared to existing ways to interact with Shapefiles.

File Geodatabase Precision… – Mapperz May 8 '13 at 20:07
Interesting, thanks for the link. – Dan May 8 '13 at 20:34
One con I'd add to shapefiles is the field name length limit. Since they use dbfs as the table storage, they're only 13 character names, which often results in names like "CALUAFID" - not very useful to someone unfamiliar with the data, and engrains bad habits in new users who aren't used to anything else. All the benefits you mention are true. I'd also like to add that the database/feature class precision can be set, so if incredibly high accuracy is important, you still can work with them, but you must be mindful – nicksan May 15 '13 at 13:56

Another advantage of a fgdb over shapefiles is that features in a fgdb can have true curves. In shapefiles, curves are composed of arbitrarily small straight line segments. I'm not sure about personal gdbs.


if you want full-blown geodatabase capability (Coded Value Domains, Relationship Classes, Topologies, Geometric Networks, etc blah blah, without the complexity or admin overhead of relational geodatabase, AND/OR you want the fastest drawing, cursor, and geoprocessing performance, File Geodatabase is the way to go. Local disc access is much faster than a remote relational geodatabase. FGDB, like shapefiles, use floating point coordinates, not integer, for better and worse. FGDBs can be fragile, being complex, binary, and proprietary, so keep lots of backups. Shapefiles are the dumbest but the most widely supported, and can be quite speedy to work with too. Relational geodatabases allow you to use SQL, including spatial SQL, which can be quite flexible and convenient for ad-hoc analysis or applications. Personal GDB hasn't been worth monkeying with since the advent of FGDB - buggy, slow, file size limitations.


Not the answer you're looking for? Browse other questions tagged or ask your own question.