Oracle Spatial and Graph is a paid database option — not a feature bundled into Oracle Database Enterprise Edition at no additional cost. Yet it is one of the most commonly overlooked licensing obligations in enterprise Oracle estates. Development teams build GIS capabilities, load spatial data types, or use location intelligence functions without ever raising a procurement request, because the Spatial objects appear built-in to the database schema. The result is an unlicensed Oracle Spatial deployment that generates significant back-license exposure when Oracle's LMS scripts identify active SDO_GEOMETRY usage, spatial index queries, or Workspace Manager calls. Understanding exactly what triggers an Oracle Spatial license requirement, what the LMS scripts look for, and how to right-size or remediate your position is the foundation of managing this specific compliance gap.
Oracle Spatial and Graph is a separately licensed Oracle Database option that provides native support for geographic information system (GIS) data, location intelligence workloads, and graph analytics within Oracle Database. It was previously known as Oracle Spatial, then Oracle Spatial and Graph, and the current commercial name includes both spatial capabilities and property graph / RDF graph features within a single option license.
Spatial functionality within Oracle Database is built around the SDO_GEOMETRY data type, a spatial indexing layer (R-Tree and Quad-Tree indexes), a suite of geometry functions (SDO_GEOM, SDO_WITHIN_DISTANCE, SDO_RELATE), and integration with Oracle Maps, Oracle MapViewer, and Oracle Locator. The Locator component — a subset of Spatial functionality providing basic geometry storage and simple proximity queries — is included in Oracle Database Enterprise Edition and Standard Edition 2 at no additional cost. The full Oracle Spatial and Graph option adds advanced spatial analysis, network data model support, georaster data, topology data model, routing engine, and property graph and RDF graph capabilities.
The practical problem: the boundary between Oracle Locator (free) and Oracle Spatial (licensed) is not cleanly enforced within the database engine. Developers can invoke functions that technically require the Spatial option license while working in environments where only Locator was intended to be used. Oracle's position is that if a Spatial-only function has been called — regardless of intent, developer awareness, or volume of use — the Spatial option is required for the entire database processor or Named User Plus count.
For a broader view of how Oracle database options create compliance exposure, see our guide on Oracle Database Options licensing and the detailed analysis of Diagnostics Pack accidental enablement — the most common comparator scenario.
Oracle Spatial license requirements are triggered by use — not by installation. Oracle Spatial and Graph is installed into every Oracle Database Enterprise Edition as part of the standard database installation. The presence of spatial schemas and data types in the database does not itself constitute use. What triggers the license obligation is active use of features that fall outside the Oracle Locator boundary.
Oracle Locator provides the following capabilities without requiring a Spatial license: storage of point, line, and polygon geometries using SDO_GEOMETRY; basic spatial indexing; WITHIN_DISTANCE queries limited to point data; simple spatial joins for latitude/longitude coordinates. These Locator capabilities are documented in Oracle's Database Licensing Information User Manual and are available in EE and SE2.
The Spatial and Graph option is required when your database uses any of the following: advanced spatial analysis functions (SDO_GEOM.SDO_AREA, SDO_GEOM.SDO_LENGTH, SDO_GEOM.SDO_BUFFER, SDO_GEOM.SDO_INTERSECTION and similar); linear referencing system functions; network data model (SDO_NET); topology data model (SDO_TOPO); raster data (SDO_GEORASTER); routing engine (SDO_GCDR); spatial web services; property graph (PGQL, PGX); RDF graph (SEM_MATCH, SEM_APIS); or any function documented as requiring the Spatial and Graph option in Oracle's DLIUM.
The challenge is that many of these functions were introduced into application code by developers who were not aware of the licensing boundary. GIS development teams routinely use buffer analysis, area calculations, and topological operations as standard spatial programming practice — without realizing that each of these calls generates a license obligation covering the entire database server.
Our Oracle Compliance Review identifies every database option in active use across your estate — including Spatial — before Oracle's LMS scripts arrive. We've eliminated $500M+ in potential back-license claims for enterprise clients.
Oracle's LMS audit scripts — the USMM (Usage Measurement Script for Middleware) and the Database LMS scripts — identify Oracle Spatial usage through multiple detection vectors. Understanding what these scripts measure is the only reliable way to assess your exposure before an audit commences.
The primary detection mechanism queries the V$OPTION view, which reports the status of each licenced database option. For Oracle Spatial, the relevant entry is 'Spatial'. A status of 'TRUE' in V$OPTION indicates that the Spatial option is installed and available, but does not by itself confirm use — all options show as TRUE in a standard EE installation. Oracle's scripts go further by querying audit trail data and database feature usage statistics.
The DBA_FEATURE_USAGE_STATISTICS view is the key evidence source. Oracle Database 11g and later automatically tracks feature usage in this view, recording a 'LAST_USAGE_DATE' and 'CURRENTLY_USED' flag for each database feature. The LMS scripts extract SDO_GEOMETRY and spatial function usage from this view and from V$SQL and AWR data. Specific queries look for: calls to SDO_GEOM subprograms not included in Locator; SDO_NET and SDO_TOPO package usage; SDO_GEORASTER calls; PGQL or PGX invocations; and any SEM_MATCH RDF graph queries.
Critically, DBA_FEATURE_USAGE_STATISTICS persists historical usage data. If a developer used an advanced Spatial function six months ago during a proof-of-concept that was never deployed to production, that usage may still appear in the feature usage statistics — and Oracle will claim the Spatial option license was required from that date forward. Cleaning up historical usage data requires careful database administration and, in some cases, is not possible without Oracle's cooperation.
Our Oracle Audit Defense service includes a pre-audit spatial usage analysis that replicates Oracle's LMS detection logic — giving you the evidence picture before Oracle does. See the detailed process in our LMS scripts guide.
Oracle Spatial and Graph is licensed as a database option — meaning its cost is calculated on top of the Oracle Database Enterprise Edition license cost, using the same metric (Processor or Named User Plus) and the same Core Factor Table multipliers. There is no SE2-compatible Spatial option; Spatial requires Database Enterprise Edition as the base license.
| License Metric | Oracle DB EE (List) | Spatial & Graph Add-On (List) | Combined List Price |
|---|---|---|---|
| Processor | $47,500 / processor | $17,500 / processor | $65,000 / processor |
| Named User Plus | $950 / NUP | $350 / NUP | $1,300 / NUP |
Oracle's list prices are rarely paid by enterprise customers. The actual negotiated price depends on your existing Oracle relationship, contract volume, Oracle master agreement or ULA structure, and Oracle's end-of-quarter sales pressure. That said, back-license claims in an audit scenario use Oracle's list pricing as the baseline — meaning enterprises without a negotiated position face the full $17,500 per-processor exposure for Spatial, multiplied by the number of processors (after Core Factor Table adjustment) on every server where the Spatial option was used.
For a database server with 4 dual-socket Intel Xeon CPUs (2 x 16 cores = 32 physical cores, Core Factor 0.5, = 16 processor licenses), the Spatial back-license claim at list price would be 16 × $17,500 = $280,000 — before annual support is applied. If the usage extended over multiple years, Oracle typically claims 22% per annum support arrears on top of the license fee. A 3-year undisclosed Spatial usage on a mid-size server cluster can easily generate a seven-figure back-license claim in an LMS audit.
For a full understanding of processor licensing calculations, see our Oracle Processor Licensing guide and the Core Factor Table explained.
Oracle Spatial audit exposure is especially prevalent in specific industry verticals and application architecture patterns. Understanding where Oracle looks and what it finds allows enterprises to prioritize their compliance review activities.
Industry verticals at highest risk include utilities and energy (pipeline routing, asset location, network topology); telecommunications (network mapping, coverage analysis, cell tower location); logistics and supply chain (route optimization, geofencing, delivery zone analysis); local government and public sector (planning applications, cadastral data, infrastructure mapping); retail (store location analysis, trade area modelling, customer geography); and insurance (risk area modelling, catastrophe analysis, property location).
Common application patterns that trigger Spatial licensing include: any application using Oracle's SDO_WITHIN_DISTANCE with polygon or line geometries beyond point-to-point proximity; EBS or JD Edwards modules that use spatial data for fleet management or asset tracking; custom middleware using Oracle Spatial JDBC extensions; GeoServer or ArcGIS instances connected to Oracle Database with spatial data types; and data warehouse environments where spatial aggregation functions are used for regional analysis.
The Workspace Manager overlap is another hidden trigger. Oracle Workspace Manager — which allows multiple versions of rows in a table to coexist — shares some licensing territory with Spatial when used in GIS versioning scenarios. LMS scripts examine DBMS_WM package calls in environments where SDO_GEOMETRY tables are workspace-managed, creating an additional exposure vector.
For context on how Oracle uses audit data against enterprise customers, see our analysis of Oracle audit data disclosure and the broader Oracle audit defense playbook.
Our team has defended dozens of Oracle audits where Spatial usage was in dispute. We challenge Oracle's feature usage evidence, scope the technical boundary between Locator and Spatial, and negotiate a settlement position. See our Healthcare Compliance Remediation case study — $6M in risk eliminated.
When an enterprise discovers unlicensed Oracle Spatial usage — through an internal self-assessment, a pre-audit compliance review, or during an active LMS audit — the response options fall into two categories: remediation (eliminating the use) or compliance (acquiring the license).
Technical remediation requires identifying and removing every call to Spatial-licensed features from application code and stored procedures. This is more complex than it sounds. Oracle does not provide a clean 'disable Spatial' mechanism at the database level. You cannot uninstall the Spatial option without rebuilding the database. What you can do is audit your application code and PL/SQL packages to identify and rewrite or remove functions that fall outside the Locator boundary. After code changes are deployed, you need to wait for DBA_FEATURE_USAGE_STATISTICS to age out — which Oracle typically requires to show 12+ months of non-usage before accepting a 'no longer used' position in an audit.
The Oracle Locator boundary is often misunderstood by development teams. Locator allows storage and basic querying of geometries but disallows advanced analysis. A practical approach is to review your SDO_GEOM, SDO_NET, SDO_TOPO, and SDO_GEORASTER package usage, identify which calls fall outside Locator, and either rewrite using open standards (PostGIS functions in application code, for example) or accept that a license is needed.
License acquisition is appropriate when: the Spatial functionality is genuinely business-critical; migration to an alternative would be more expensive than the license cost; or the audit is already underway and technical remediation cannot be completed before Oracle's measurement date. When acquiring Spatial licenses retroactively in an audit settlement, the negotiation focus should be on the back-period calculation (Oracle typically claims 5+ years; challenge this based on actual feature usage first-date evidence), the annual support inclusion (aim to exclude years where usage is contested), and the number of processor licenses in scope (challenge Oracle's server scoping if the Spatial usage was limited to specific database instances, not the entire cluster).
Our Oracle Compliance Review service provides the technical evidence baseline required for both remediation scoping and audit negotiation. Combined with our Oracle Audit Defense service, we protect enterprises from Oracle's tendency to overstate the back-license claim value in spatial disputes.
The strategic answer to Oracle Spatial licensing cost — particularly for enterprises reconsidering their Oracle Database dependency — is migration to open-source spatial platforms. The geospatial open-source ecosystem is mature, production-grade, and supported commercially by multiple vendors.
PostGIS (PostgreSQL extension) is the most direct Oracle Spatial equivalent and the most widely adopted open-source spatial database. PostGIS implements the OGC Simple Features standard, provides geometry, geography, and raster data types, supports topology, and includes a richer function library than Oracle Spatial in many respects. The SDO_GEOMETRY to PostGIS geometry type mapping is well-documented, and Oracle-to-PostgreSQL migration tooling exists specifically for spatial data workloads. Our guide on Oracle to PostgreSQL migration analysis covers the full transition framework.
SpatiaLite is an extension to SQLite that provides spatial capabilities for smaller-scale deployments where Oracle SE2 was being used with basic spatial requirements. For lightweight GIS workloads, SpatiaLite eliminates both the Oracle Database and the Oracle Spatial license obligation.
MariaDB includes geometry data types and spatial indexes as part of its core engine (InnoDB support for spatial indexes was added in MySQL 5.7 / MariaDB 10.x). For applications using only basic geometry storage and proximity queries, MariaDB spatial support may be sufficient without PostGIS complexity.
Cloud-native alternatives include BigQuery GIS (Google Cloud), Amazon Aurora with PostGIS, and Azure Cosmos DB for NoSQL spatial queries. These platforms shift spatial workloads entirely to managed cloud services, eliminating the Oracle Spatial license while reducing infrastructure overhead. See our Oracle Database Licensing Guide 2026 for how these migration paths affect the overall Oracle license estate.
For enterprises that need Oracle Spatial functionality and have determined that migration is not feasible in the near term, cost reduction focuses on four levers: accurate scoping, metric optimization, contract negotiation, and support cost management.
Accurate scoping is the first lever. Oracle's LMS audit methodology tends to claim the Spatial option for every processor in a RAC cluster or every server in a VMware environment where Spatial usage has been detected — regardless of which specific instances are involved. A forensic technical analysis often demonstrates that Spatial usage was confined to a specific database instance on a specific server, and that Oracle's broader scoping claim is not supported by the feature usage evidence. Reducing the number of processors in scope directly reduces the back-license and ongoing license cost.
Named User Plus optimization is often overlooked for Spatial. If Oracle Spatial is used exclusively by a known, bounded population of GIS analysts — and that population is smaller than the NUP minimum (10 per processor) — then switching from Processor metric to Named User Plus metric can substantially reduce the Spatial license cost. This requires demonstrating that no other users or system processes have access to the Spatial-licensed database instances.
Oracle agreement and ULA structures can include Oracle Spatial as a product. If your Oracle estate is large enough to justify an Oracle master agreement or ULA negotiation, including Spatial in the product list eliminates the per-option cost and may be justified by your actual spatial usage pattern. Our Oracle ULA Advisory service evaluates whether unlimited deployment rights for Spatial represent value given your GIS growth trajectory.
Annual support cost reduction applies to Spatial licenses as it does to all Oracle products. The standard 22% annual support cost applies to both the base Database EE license and the Spatial option add-on. Third-party support providers, including Rimini Street, support Oracle Spatial deployments — and our Oracle Support Reduction service has achieved 50%+ annual maintenance savings for enterprises that have stabilised their Spatial deployments and do not require Oracle's enhanced support for active GIS development.
The complete enterprise guide to Oracle Database edition licensing, options, metrics, and cost reduction — 60+ pages of expert analysis.
Download Free White Paper →Weekly briefings for Oracle stakeholders: audit alerts, negotiation tactics, Java updates, and compliance guidance. Read by 2,000+ enterprise Oracle teams.