Skip to main content
  • EN

Since FME lives (thrives!) in the lands-between-realms I'm thinking this is the best place to ask this question and hook knowledgeable reponses. There are more eyeballs in the Esri and Stack Exchange community forums but they're less likely to have the broad horizon to horizon perspective combined with life in the tunnels found here.

 

What are the trade-offs to consider when deciding between native DB spatial type or Esri Enterprise Geodatabase (or both)?

 

Where 'native' means PostGIS for Postgres, SQL Server Spatial, OGC in Mysql, etc., etc. Assume equal proficiency of staff and resources is or will be made available. Licensing et al is consequential but not determining.

 

Content is a mix of spatial and non-spatial. It's hard to say which is more. By volume in terms of storage it's spatial - a lot of wildlife telemetry, survey and observational data. However by number of tables the non-spatial will probably outnumber spatial in the long run. That said everything is spatial adjacent even when not intrinsically spatial. Very roughly there are 20 million records across all types at present with annual growth rate of 10 to 15%.

 

Majority of infrastucture is on-premise for at least next 5 years, though cloud for this and that are talked about constantly.

 

Data clients are split between traditional desktop GIS (ArcMap, Arc Pro, Qgis), web maps and services, mobile apps (Survey 123, Field Collector, Mergin Maps), custom applications in language du jour (e.g. C-sharp & Blazor), and programmatic tools and code (e.g. Jupyter). Our org is invested in Esri ecosystem across all strata but aiming to be as agnostic as practical long term.

 

Thanks in advance for your thoughts.

Some general observations based on projects I've worked on:

  • For the majority of Esri data consumers (ArcGIS tools), it's probably much easier to stick with SDE for the back end.
  • If your data consumers are not in the Esri ecosystem (FME, custom development), I'd recommend the native data types, when possible, due to licensing and also performance (one less middle layer)
  • I believe you can sometimes use native data types and put SDE on top for the clients that require it, but I'm not quite up to date on how well this works, there used to be some rather important limitations in the past. If you can accept any current limitations (see the relevant Esri docs), this might be an interesting option to consider. But you'll have to be really careful that you're not writing non-SDE compatible geometries from your custom apps, etc.
  • I generally find that native data types are less of a black box, although it depends on the DB implementation.
  • The Esri ecosystem is pretty unbeatable on functionality for GIS heavy operations, e.g. topologies and other advanced functionality. But if you only ever need to store e.g. points, lines and polygons (and perhaps rasters), most modern DBs support them very well with native data types.
  • SDE is predictable in functionality across DB platforms, where as native data types can vary quite a lot in implementation and functionality, which can be an important consideration if you plan on migrating your database in the future.

It's a bit of an unstructured list of thoughts, but I hope it helps.

Some general observations based on projects I've worked on:

  • For the majority of Esri data consumers (ArcGIS tools), it's probably much easier to stick with SDE for the back end.
  • If your data consumers are not in the Esri ecosystem (FME, custom development), I'd recommend the native data types, when possible, due to licensing and also performance (one less middle layer)
  • I believe you can sometimes use native data types and put SDE on top for the clients that require it, but I'm not quite up to date on how well this works, there used to be some rather important limitations in the past. If you can accept any current limitations (see the relevant Esri docs), this might be an interesting option to consider. But you'll have to be really careful that you're not writing non-SDE compatible geometries from your custom apps, etc.
  • I generally find that native data types are less of a black box, although it depends on the DB implementation.
  • The Esri ecosystem is pretty unbeatable on functionality for GIS heavy operations, e.g. topologies and other advanced functionality. But if you only ever need to store e.g. points, lines and polygons (and perhaps rasters), most modern DBs support them very well with native data types.
  • SDE is predictable in functionality across DB platforms, where as native data types can vary quite a lot in implementation and functionality, which can be an important consideration if you plan on migrating your database in the future.

It's a bit of an unstructured list of thoughts, but I hope it helps.

Thank you David! This is helpful.

Reflection continues.

Reply


Community Stats

30,363
Posts
115,370
Replies
38,145
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.