Note:
Database connections are supported in Insights in ArcGIS Enterprise and Insights desktop.
Relational databases
Data in relational databases is stored in tables. Each table is a set of rows and columns. Each column has a type, and many databases support one or more native spatial data types.
The data type determines the following:
- Which values can be stored in a column
- Which operations can be performed on the data in that column
- How the data is physically stored in the database
ArcGIS Insights supports direct access to specific data types from a list of supported database management systems. When accessing a database table directly through an add data workflow, Insights filters out any unsupported data types.
Note:
Database tables accessed through Insights are read-only and cannot be edited. This includes cases in which a dataset has been shared with others in your organization as a feature layer, and edits are being attempted in a client application other than Insights.
Tip:
When using data from a database causes an error in Insights in ArcGIS Enterprise, detailed information is added to the ArcGIS Server logs on your portal’s hosting server site. Work with your ArcGIS Server administrator to diagnose and resolve any issues.
Connecting to a database
Before you can use data from a database in Insights, you must create a database connection. Before you create a database connection, certain prerequisites must be met.
The process of establishing a database connection in Insights in ArcGIS Enterprise creates a Relational Database Connection item on the portal’s Content tab and the Connections tab on the Insights home page. This item can subsequently be shared with others. Sharing a database connection item only shares the ability to browse the contents of the database. The credentials used when establishing the connection are never exposed to those with whom the item has been shared.
If an issue arises while creating a database connection, see Troubleshoot a database connection.
Caution:
If you're having trouble using a database connection that previously worked in Insights, you may need to update the connection. Deleting the database connection will render any dependent datasets inoperable. Only delete a relational database connection when you are sure no datasets are dependent, or you purposefully want to disable upstream datasets.
While database connections update to reflect the current state of the database, datasets reflect the schema of the table or view at the time of dataset creation. Datasets created from a database connection are dependent on the schema, naming conventions, and existing spatial data objects (geometry types and spatial reference identifiers) of the database. Renaming or deleting tables and views referenced by a dataset will break the dataset. Likewise, field names and data types must remain static for a dataset to be functional.
Geodatabases
In Insights, you can create a connection to a supported Microsoft SQL Server, Oracle, SAP HANA, or PostgreSQL database that has a nonversioned enterprise geodatabase defined. If the geodatabase is versioned, the data must be unregistered as versioned to work in Insights. Currently, only geodatabase user tables that were not created under the sde user schema can be viewed and accessed from Insights. Insights does not work directly with file and personal geodatabases.
Spatial datasets
Database tables do not need to be spatially enabled to be used in Insights. A spatially enabled table contains a field that Insights interprets as a location field. When a location field is detected in a table, Insights makes a number of assumptions described in the following sections.
Single spatial column
Insights only supports one spatial column per database table. You can choose which spatial field will be used as the location field by clicking the location field button 
next to the table name under Selected Data and choosing from the list of spatial fields. 
Supported geometry types
The databases Insights supports are compliant with the Open Geospatial Consortium (OGC) and International Organization for Standardization (ISO) standard for simple feature access. The following table lists supported OGC/ISO geometry types, along with how they are interpreted in Insights:
| OGC/ISO | Geometry type |
|---|---|
POINT | Point |
LINESTRING MULTILINESTRING | Line |
POLYGON MULTIPOLYGON | Area |
Insights does not enforce the OGC/ISO standards. When an unsupported geometry type is encountered, an error will occur.
Same geometry type
It is expected that all geometries in a spatial column share the same geometry type; for example, all point, all line, or all area. The geometry type for a dataset is determined by querying the first row in the table where the spatial column is not a null value.
Insights does not check for the same geometry. Unexpected results or errors may occur if rows in the dataset fail to meet this expectation.
Same spatial reference
It is expected that all geometries in a spatial column share a common spatial reference identifier (SRID). The spatial reference of the dataset is determined by querying the first row in the table where the spatial column is not a null value.
Insights does not check for the same spatial reference. Unexpected results or errors may occur if rows in the database fail to meet this expectation.
Project on the fly
Insights displays spatial data in the spatial reference system of your default basemap. This is for display and query purposes only; the underlying data is not altered. If the underlying geographic coordinate systems of the two spatial reference systems are incompatible, alignment and accuracy problems may be observed. To ensure fast performance and accurate display of spatial data, the spatial reference system of your spatial datasets should match the spatial reference system of the default basemap.
Note:
If your data is from a SAP HANA database and it is not possible for the spatial reference system of your spatial datasets to match the spatial reference system of the default basemap, it is recommended that unbounded SRIDs be used for your spatial datasets. Unbounded SRIDs will ensure that your spatial data can be displayed even if the extent of your organization's default basemap exceeds the extent of the spatial reference system of your spatial data.
Spatial operations
When performing spatial aggregation or spatial filtering using two datasets from a database connection, the spatial data in both datasets must have the same spatial reference system. For SQL Server database connections, the data must also have the same data type (geography or geometry).
Coordinate dimensionality
Coordinate dimensionality is defined by the x-, y-, z-, and m-coordinates for each vertex in a geometry. Insights ignores any z- and m-coordinates returned from the database.
Optimizing database content for performance
Properly configured and tuned databases always perform best. The following represent some considerations database administrators should make for ensuring an optimal user experience in Insights:
Up-to-date database statistics
Database statistics are used by the database management system optimizer to choose the optimal plan for the query being run. Up-to-date statistics will help maintain query performance.
Primary key constraints
A primary key constraint uniquely identifies each row in a database table. Although not a requirement, it is recommended that a primary key be defined on database tables. Further, a single integer type field is recommend for a primary key.
Use both attribute and spatial indexes
If your database platform supports it, index any fields used for querying or rendering your data.
Common spatial reference
If possible, keep all data in a common spatial reference, and ideally, use the same projection as your organization’s default basemap. This will avoid on-the-fly projection calculations when drawing data on a map and will prevent errors during spatial analysis.
Simplified data
Use the most simplified or generalized version of spatial data that will satisfy the visualization and analysis requirements of your organization. Simplified data has fewer vertices and line segments than complex datasets, meaning it will draw faster and analysis results will be returned sooner.
Spatial joins at ETL time
Spatial joins at run time can be expensive. Because spatial data does not change often, it’s worth it to pay the price of performing spatial joins on data in the database once, and, at run time, performing attribute joins to achieve the same results.