Oracle Spatial and Graph Licensing: The Option That Surfaces in Audits

Oracle stopped selling Spatial and Graph as a priced option on 5 December 2019, yet it remains one of the most common findings in Oracle audit reports because feature-usage data, legacy program documentation, and unrestated contracts all point the other way. This guide sets out exactly where the paid boundary sits, what a claim is worth at list, and the evidence that kills a false positive before it becomes a purchase order.

The Two-Sentence Version Every Oracle Customer Needs

Here is the whole guide in two sentences. As of 5 December 2019, Spatial and Graph stopped being a separately priced option of Oracle Database, and its functionality now attaches to the underlying database license, on Enterprise Edition, Standard Edition 2, Personal Edition, and every Oracle Database Cloud Service tier, for database version 11.2 and higher, provided support is active. The catch, and it is the reason this page exists: that entitlement was granted by Oracle policy and documented in the 19c Licensing Information User Manual, not necessarily in the ordering document your organization signed in 2014, and Oracle's audit teams still raise Spatial findings against pre-19c estates where the contractual program documentation was never restated. House of Brick's analysis puts the boundary plainly: the 19c LIUM shows Spatial and Graph as an included option across editions, while the 12c program documentation still describes it as an option that "can be purchased with Oracle Database Enterprise Edition." If your contract points at 12c program docs and your database is running 12.1, an auditor has a document to wave, and you need a better one.

So run three tests before you engage on any Spatial claim. First, the release test: what database version is actually running on the instance that generated the finding, because 19c and later carry the included-option language and pre-19c releases do not. Second, the contract vintage test: pull the ordering document and its incorporated program documentation, and check whether it predates December 2019 and whether Spatial appears as a priced option. Third, and this is where most claims die, the feature test: separate genuine Spatial code from Oracle Locator, which has always shipped free with the base database and which Oracle's own installers enable without anyone asking. Get those three answers on paper before you concede anything, and treat the finding the same way you would treat any other accidental-use option claim in an Oracle audit.

Entitlement came from Oracle policy in December 2019, but your ordering document may still say Spatial is a priced option, and that is the document an auditor will read.

What Changed on 5 December 2019, and What Did Not

The change record is short and worth quoting back at Oracle verbatim. On 5 December 2019, William Hardie, VP of Database Product Management, posted on the Oracle Database blog that the Machine Learning (formerly Advanced Analytics), Spatial and Graph features "may be used for development and deployment purposes with all on-prem editions and Oracle Cloud Database Services." Oracle's own OAA/OSG Licensing Change FAQ went further and stated the operative legal point: OAA and OSG "are no longer options of Oracle Database," and their functionality "is now associated with the Oracle Database license," covering all licensed EE and SE2 users with active support and all Oracle Database Cloud Service editions with active subscriptions, including Standard Edition, Enterprise Edition, EE High Performance, and EE Extreme Performance. The commercial confirmation arrived the same day: the 5 December 2019 price list no longer carries Spatial and Graph as a purchasable Database option. Before that, per Miro Consulting, the option listed at $350 per Named User Plus and $17,500 per Processor, which is still the rate an unrestated pre-2019 estate will be priced at in a claim.

Now the three things that did not change, because this is where Oracle keeps its leverage. First, active support is a condition, not a courtesy. The entitlement flows to customers with active support contracts and active cloud subscriptions. Let support lapse on a legacy CSI and the policy grant underneath your Spatial usage becomes considerably harder to argue. Second, SE2 gained the right, not the horsepower. Mike Dietrich, Oracle VP for Database Upgrade, wrote on 6 December 2019 that all features are included "only to the extent the underlying database supports them," and because SE2 does not support parallel operations, Spatial operations execute serially on SE2. He also noted SE2 may require an extra patch beyond the base installation. Third, Oracle's own FAQ conceded that support for SE2 and certain cloud deployments "depends upon a forthcoming update." Entitlement and technical enablement were not simultaneous.

That gap between the right and the capability is not a footnote, it is negotiation material. Oracle unbundled a $17,500-per-processor option and handed it to the installed base as an inducement to keep paying support, which on EE at a $47,500 list processor price runs roughly $10,450 a year at 22 percent. When Oracle raises a Spatial finding against you, the argument writes itself: you are being billed for a capability Oracle itself declared to be a benefit of the support stream you already fund. In our negotiation experience, that framing works best at renewal, where the audit and the support renewal are two halves of the same revenue event. Attach the Spatial resolution to the renewal signature and demand written confirmation that the December 2019 policy applies to your CSIs and releases. Do not settle it in isolation.

Where the Money Sat: List Prices and What a Claim Is Worth

Before 5 December 2019, Spatial and Graph carried a list price of $17,500 per Processor or $350 per Named User Plus, and it was licensed on the same metric and the same quantity as the Enterprise Edition database sitting underneath it. That last clause is where the money lives. An option is never priced against the cores that actually executed the feature; it is priced against every core licensed for the database on which the option is installed. Auditors know this, which is why a single SDO_GEORASTER table on one non-production instance can produce a claim that dwarfs the estate that created it. Size the exposure before you argue about it: take the licensed Processor count for the database in question, multiply by $17,500, add 22 percent annual support, and then decide how many years of backdated support Oracle is likely to demand. In our negotiation experience, opening LMS positions routinely reach back to the first date of demonstrable feature usage, not the date of the audit notice, and that backdating is usually the larger half of the number.

Work a concrete case. A 16-processor Enterprise Edition estate means 32 physical cores on x86 hardware at the 0.5 core processor licensing factor, and every core in the aggregation counts before the factor is applied, with fractions rounded up. Spatial at 16 Processors is $280,000 at list. First-year support at 22 percent adds $61,600. If Oracle backdates three years of support on the theory that the feature was in use from the 12c upgrade forward, the claim reaches roughly $464,800 before any discount conversation begins. Now apply the multiplier that catches most buyers off guard: if that same 12c binary was cloned into development, test, and a disaster recovery standby that is not covered by the ten-day failover rule, the Processor count Oracle asserts is not 16 but 40 or more, and the same arithmetic produces a claim north of $1.1 million. Nothing in that number reflects business value. It reflects the installed footprint of a schema object.

An option is never priced against the cores that executed the feature; it is priced against every core licensed for the database it sits on.

Two sizing rules will save you a week of internal debate. First, if the estate is licensed by Named User Plus rather than Processor, the minimum floors govern: 25 NUP per Processor on Enterprise Edition and 10 per Processor on Standard Edition 2, and you license the higher of the floor and real headcount. A 16-processor EE estate carries a 400 NUP floor, so the Spatial claim at $350 per NUP is $140,000, materially cheaper than the Processor route, and worth checking before you concede the metric Oracle proposes. Second, remember what a Spatial finding drags behind it. Oracle's own Licensing Information User Manual grants Spatial only a restricted-use license to Partitioning, so an audit team that finds partitioned spatial index subobjects will often open a separate Partitioning line at $11,500 per Processor. Score both exposures together, then read our broader treatment of how the Oracle database options and packs stack accumulates accidental-use findings before you respond to anything in writing.

Locator Versus Spatial: The Boundary That Still Governs Legacy Estates

For any database at 18c or below, and for any contract whose program documentation was never restated to the December 2019 terms, the Locator versus Spatial line is still the operative legal test. It does not matter what Oracle's website says today. It matters what the ordering document and the program documentation in force at the time of your purchase said, and for 12c that documentation lists Spatial and Graph as an option that can be purchased with Enterprise Edition. Oracle's 12.2 Developer's Guide is blunt: Spatial and Graph is a priced option available only with Enterprise Edition, and it includes all Locator features plus features not available with Locator. Locator, by contrast, shipped free with Standard Edition One, Standard Edition, Enterprise Edition, and Express Edition, and included the data types, operators, and indexing capabilities of Spatial and Graph plus a deliberately limited set of subprograms. Your defence, therefore, is not a policy argument. It is a schema argument: prove that every object and every call in the estate falls inside the free set.

The 19c inflection point is the sentence to put in front of any auditor arguing about a modern estate. Oracle's 19c Spatial and Graph Developer's Guide preface states plainly that all Spatial and Graph capabilities are available with all editions, that there is no longer any distinction between features available with Spatial and Graph and those available with Locator, and that Locator users should simply move to Spatial because no extra-cost license is required. That is Oracle's own documentation, published by Oracle, and it settles the question for 19c and 23ai deployments running on a support contract. It does not, however, retroactively rewrite a 12c ordering document, and Oracle audit teams will not volunteer that distinction in your favour.

Three practical consequences follow, and each is worth acting on this week. Run them alongside our guidance on how an Oracle audit functions as a revenue event with a counter at every step.

• Version-map the estate first. Every database at 19c or above with active support is defensible on Oracle's published documentation alone, which typically removes 60 to 80 percent of a raw feature-usage finding in the estates we handle. Spend your evidence budget on what remains.
• On pre-19c instances, the test is subprogram-level, not object-level. An SDO_GEOMETRY column with an R-tree index is Locator. A call to SDO_LRS.CONVERT_TO_LRS_GEOM, an SDO_GEOR object, or a Geocoder schema is a Spatial finding, and you should assume Oracle's script will report it.
• Check whether Locator arrived without anyone asking. Oracle's 12.2 documentation confirms Locator is installed as a byproduct of Multimedia, which DBCA and the Enterprise Edition installer configure by default. Installed-and-unused Locator is not a licensing event; installed-and-unused Spatial packages on a pre-19c release still need an evidence pack, not an assumption.

The Version Trap: Why 12c Contracts Still Carry a Bill

Here is where the largest live exposure sits, and it is not a technical problem, it is a document problem. Oracle's 19c Licensing Information User Manual, Table 1-14, lists Spatial and Graph as an included option across editions, which is the evidence buyers wave at auditors. But the 12c program documentation was never restated. It continues to describe Spatial and Graph as an option that "can be purchased with Oracle Database Enterprise Edition," and that document, not the 5 December 2019 blog post, is what your 2015 ordering document incorporates by reference. So a customer running 12.2.0.1 under an OLSA signed in 2015 has a fully coherent Oracle-authored paper trail arguing the option is chargeable at $17,500 per processor, and a separate Oracle-authored paper trail, published four years later against a different release, arguing it is free. In 25 years of arguing this vendor's own documentation back at it, the pattern is consistent: Oracle's audit teams cite the documentation that matches the contract, not the documentation that matches today's marketing. Do not assume a policy announcement travels backward through your paper.

The defensible position is that the OAA/OSG FAQ states the entitlement applies from database version 11.2 upward, which covers 12.1 and 12.2 on its face and is a contemporaneous Oracle statement rather than a third-party blog. That is a strong argument, but it is an argument, not an amendment. Treat it as leverage material rather than a defense you can bank. The remedies, in priority order, are practical. First, confirm which LIUM edition matches your installed release, not your latest release, because auditors will map findings release by release across the estate. Second, capture the OAA/OSG FAQ and the 5 December 2019 blog post with retrieval dates and archived copies, since Oracle has quietly rewritten licensing web pages before and you want the version that existed when you relied on it. Third, and this is the only thing that actually closes the exposure, get the change written into your contract. A one-line amendment stating that Spatial and Graph functionality is included with the Database license for all versions 11.2 and above, across all deployed editions, costs Oracle nothing and removes a seven-figure claim from your renewal. Ask for it during a renewal, a cloud commitment, or a support reinstatement, when Oracle wants something back. A written confirmation from an Oracle contracts representative is the fallback; a sales email is worth less but is still better than a screenshot of a blog.

One further trap sits in the same manual. Table 1-17 shows that Spatial and Graph use carries only a restricted-use license to Partitioning, not a full Partitioning entitlement. Restricted use means Partitioning invoked by Spatial internals, for example partitioned spatial indexes, is covered; partitioning your finance tables because the feature happened to be installed is not. Auditors read the DBA_PART_TABLES output, see partitioned objects outside the spatial schemas, and price the full option at list. If your DBAs discovered partitioning through a spatial deployment, unwind that usage or license it deliberately before anyone runs a script. The same restricted-use logic appears across the wider Oracle database options and management packs audit trap, and it is the single most misread line in the manual.

Oracle's audit teams cite the documentation that matches the contract, not the documentation that matches today's marketing.

How Spatial Gets Enabled Without Anyone Choosing It

Nobody in your organization decided to deploy Spatial. That is the point. Oracle's own 12.2 documentation states that Locator installation depends on the installation of Oracle Multimedia, and that Multimedia is installed and configured with Oracle Database. During Multimedia installation, Locator is installed. The practical consequence, confirmed by vendor install guides including Temenos, is a clean split: any database created through DBCA or the Enterprise Edition installer receives the SDO_GEOMETRY type and the MDSYS schema by default, while databases built from manual creation scripts typically do not. Your DBAs never ticked a box. The installer ticked it for them, on every database, going back years.

From there, the enablement paths multiply, and each one is a plausible audit finding:

• Application vendors shipping spatial data types. Utility billing, telecoms inventory, insurance rating, and logistics packages define SDO_GEOMETRY columns in their schemas. You inherit the usage flag on install, before a single user logs in.
• ArcGIS, FME, and Safe Software middleware. Esri's Oracle geodatabase and FME writers create MDSYS-dependent objects and call spatial operators as a matter of course. GIS teams procure these tools outside the database governance process entirely.
• Upgrades that install components absent from the source. An 11.2 to 19c upgrade can add registry components the source database never had, converting a genuinely Locator-only estate into one with a broader footprint.
• Clones and refreshes into non-production. A production copy dropped into dev, test, UAT, and DR inherits every component and every feature-usage record. One production spatial deployment becomes five licensable environments, and Oracle prices options on the same metric and quantity as the database underneath, so a 16-processor clone is a 16-processor claim.

The reader move is inventory, and it is a two-hour job. For every database, record whether it was created via DBCA or from manual scripts, then query DBA_REGISTRY and filter on components where STATUS is INSTALLED VALID, distinguishing "Spatial" from "Oracle Multimedia" and "Oracle Locator" line by line. Cross-reference against DBA_FEATURE_USAGE_STATISTICS and record which schemas own the SDO_GEOMETRY columns. Installed is not used, and used by an application vendor is not used by you, but you cannot make either argument until you know which databases fall where. Build that inventory before Oracle asks, because as the audit playbook and its counters makes plain, the party holding the evidence controls the framing of the finding.

The Audit Script, the False Positive, and the Bug Number You Need

Every Spatial claim I have seen in 25 years arrives the same way: Oracle runs options_packs_usage_statistics.sql, the output shows a row for "Spatial" or "Spatial and Graph" with a detected usage flag, and an LMS or GLAS analyst converts that row into a line item priced at the historical $17,500 per processor. Understand what that script actually is. It is a formatted query against DBA_FEATURE_USAGE_STATISTICS, a view populated by a weekly MMON sampling job that sets a boolean when it believes a feature was touched since the last sample. It is a heuristic counter, not a license audit engine. It has no visibility into your contract, your edition, your version, or whether the object it sampled was created by the installer rather than by a developer. Oracle's own script says so in its header text: usage statistics are informational only and do not represent any license entitlement or requirement. That disclaimer is not boilerplate you skim past. It is the sentence you quote back in writing, because it is Oracle's own admission that raw script output is a starting hypothesis, not a finding of non-compliance.

The second citation you need is Oracle's own bug catalogue. MOS Doc ID 1309070.1 is the master note for known issues with DBA_FEATURE_USAGE_STATISTICS, and it documents a long list of defects where the view reports usage that did not happen. The one that matters here is Bug 25661076, "DBA_FEATURE_USAGE_STATISTICS INCORRECTLY SHOWS SPATIAL USAGE IN 12C." That is Oracle telling Oracle that on the exact release family where the 12c program documentation still lists Spatial and Graph as a purchasable option, the detection mechanism produces false positives against Locator-only databases. In practice, the trigger is benign: the presence of SDO_ objects installed by DBCA, an index type reference, or an SDO_GEOMETRY column defined but never exercised beyond Locator-scope functions. Put the bug number, the doc ID, and the script's own disclaimer in the same paragraph of your written response, and the burden shifts back to the auditor to demonstrate an actual Spatial-only feature call.

Oracle's own script tells you the numbers are informational and confer no entitlement, which makes a raw output a hypothesis, never a finding.

Two discipline points, both from repeated engagements rather than any published statistic. First, never let an auditor run the script unattended or accept output you have not reproduced yourself with a timestamp and a named DBA. Second, never argue the bug in a phone call. Put it in the written response, cite the doc ID and bug number verbatim, and require Oracle to state in writing which specific Spatial-only subprogram or component it alleges was invoked. That single question resolves a large share of Spatial findings before evidence gathering even starts, and it is the same discipline that governs every accidental-use claim across the Oracle database options and management packs audit trap.

Building the Locator-Only Evidence Pack

Once you have forced Oracle to name the alleged feature, you win by producing evidence rather than argument. Note the practical asymmetry: contractually Oracle raises the flag and you have no obligation to disprove a hypothesis, but in the room, the customer who arrives with a signed, dated, reproducible pack settles at zero far more often than the customer who lectures the auditor about burden of proof. Build the pack in the order an auditor will accept it, because sequence matters. Start with component state, move to object inventory, then to actual invocation evidence, then close by demonstrating that the expensive Spatial-only components are empty. Every artefact should carry a capture timestamp, the instance name, the database version and patch level, the SQL used to produce it, and the name of the person who ran it. Auditors discount screenshots and accept scripted, repeatable output.

The invocation evidence is where cases are actually won. DBA_REGISTRY and object counts only show that Locator was installed, which the auditor already assumes. What kills the claim is captured SQL: DBA_SOURCE and DBA_DEPENDENCIES scans of stored code, plus AWR and ASH history filtered for SDO_ package calls, demonstrating that every referenced subprogram falls inside the documented Locator subset. Retention is your enemy here, so extract and preserve AWR before the default window rolls off. If your GIS platform is a third party product, add its vendor documentation confirming it targets Locator scope only. Then pair the pack with a governance statement locking the estate down going forward, the same approach you would take on an Advanced Security or TDE feature-flag dispute.

Deliver the pack as a single indexed PDF with the raw SQL appended, and send it under a cover letter that restates the entitlement position and asks Oracle to confirm closure in writing. Do not release it piecemeal.

Standard Edition 2, Cloud, and 23ai: The Three Live Edge Cases

The general rule (Spatial is included with the database license since 5 December 2019) breaks down in three places, and each one has produced real cost for buyers who assumed otherwise. On Standard Edition 2, entitlement is genuine but capability is not equivalent: Oracle's own upgrade product management stated on 6 December 2019 that features are included only to the extent the underlying database supports them, and because SE2 does not support parallel operations, Spatial functions execute serially. Oracle also flagged that SE2 may require an extra patch beyond the base installation, and the OAA/OSG FAQ conceded that support for SE2 and certain Cloud deployments depended on a forthcoming update. The practical consequence is architectural, not contractual: a spatial workload benchmarked on Enterprise Edition with parallel query and then replatformed to SE2 to save the roughly $30,000 per processor list gap ($47,500 EE versus $17,500 SE2) will miss its runtime targets, and the remediation is usually a return to EE, which is exactly the outcome Oracle prefers. Size SE2 spatial workloads on serial execution assumptions before you commit to the migration, not after.

In Oracle Cloud, the entitlement is broad and the FAQ is explicit: all Database Cloud Service editions, Standard Edition, Enterprise Edition, EE High Performance, and EE Extreme Performance, are licensed for spatial, graph, and machine learning features. That removes the compliance question but not the cost question. The unit economics differ sharply between a bring-your-own-license deployment (where you are still consuming the on-premises processor entitlement you already own, and the option question is genuinely closed) and a license-included subscription (where you are paying an hourly rate that already embeds the higher-edition premium whether or not the spatial work needs it). Autonomous Database changes this again, because scaling is by ECPU or OCPU rather than by licensed processor, so a poorly indexed spatial query that would simply run slowly on-premises translates directly into a consumption bill. Treat cloud spatial work as a runtime cost engineering problem and audit your own query plans, since no one at Oracle has any incentive to.

On 23ai, do not extrapolate. The Spatial precedent (a priced option folded into the base license) is a specific 2019 decision covering Spatial and Graph and Machine Learning, not a general direction of travel, and adjacent features have moved in the opposite direction. Property graph and the broader graph capability set have been repositioned across releases rather than left static, so the correct move is to read the 23ai Licensing Information User Manual tables for your exact release and confirm the entitlement line for each feature you actually invoke, rather than reasoning from the 19c table. In our audit-defense experience, the most expensive assumption customers make in this area is that one delisted option implies a policy of delisting; it does not, and the wider options and management packs accidental-use trap still applies in full to everything Oracle never delisted.

Negotiation Leverage: Turning a Spatial Finding Into a Concession

A Spatial finding is one of the weakest positions Oracle can hold in an audit letter, and you should treat it as an asset rather than a liability. The product is no longer sold as a database option, the price list line was removed on the 5 December 2019 list, and Oracle's own public blog post and OAA/OSG FAQ both state the entitlement flows with the database license across Enterprise Edition, Standard Edition 2, and every Database Cloud Service tier. When a compliance analyst prices a spatial finding at the historical $17,500 per processor or $350 per Named User Plus, they are quoting a rate for something Oracle's own website says customers already own. Say that back in writing, cite the FAQ URL and the blog date, and require the audit team to identify the specific contractual program documentation and release that supports a chargeable claim. In most cases they cannot, because the only surviving basis is unrestated 12c program documentation, and that is a documentation defect, not a usage defect.

Oracle is asking you to buy something its own published FAQ says you already have.

The moves that convert this into value are specific. First, refuse outright to price a delisted product at historical list; there is no current list line, so there is no anchor, and any number Oracle proposes is an invented one. Second, make a written entitlement confirmation a condition of any settlement, naming Spatial (and, if relevant, Machine Learning) as included with your database licenses across every release you run, not just 19c and later. Third, use the finding as the trigger to restate legacy program documentation across the whole estate: if your 12c ordering documents still describe Spatial and Graph as separately purchasable, every other option definition in those documents is equally stale, and a restatement exercise is cheap for Oracle to grant and durably valuable to you. Fourth, never resolve this as a standalone compliance purchase. Fold it into a support renewal negotiation or a cloud commitment discussion, where Oracle has revenue motive to concede, rather than into a remediation quote where its only motive is collection. The tactical patterns in how an Oracle audit functions as a revenue event apply directly here.

Two things to avoid. Do not volunteer a remediation purchase to make the finding go away, even a small one; buying licenses for a delisted option concedes that the option was chargeable, and that concession will be reused against you on the next legacy release in the estate. And never accept a verbal resolution. An account manager saying "we'll drop that line" has no contractual weight and does not survive personnel changes or a subsequent audit cycle. Insist on the finding being formally withdrawn in the audit closure letter, with the entitlement position stated affirmatively. If Oracle will only close it silently by omission, get your own written confirmation of the position on file and reference the FAQ, the blog date, and the Licensing Information User Manual Table 1-14 entry you relied on, so the next auditor inherits your record rather than a blank page.

What to Do First: A Seven-Day Action Plan

Nothing in this guide protects you if it stays theoretical. The work below takes one person about five working days spread across a week, and it converts an ambiguous exposure into a documented position you can hand to Oracle without improvising. Run it now, while there is no audit letter on the desk. The moment a formal notice arrives, every question you ask Oracle about entitlement becomes a negotiation move rather than a routine clarification, and the price of the answer changes.

• Day 1: build the release and edition inventory. One row per database instance: hostname, exact banner version (not "19c" but the full release), edition, and contract vintage. Flag everything at 18c or below in red. Those are the instances where the 12c program documentation still describes Spatial and Graph as an option purchasable with Enterprise Edition, and they carry a bill the 19c Licensing Information User Manual will not cover.
• Day 2: run the technical inventory. Query DBA_REGISTRY for the Spatial component and its status, then inventory SDO_ objects, schemas, and any use of linear referencing, GeoRaster, or Geocoder. Separate "installed" from "used." Installed via Multimedia or DBCA is a false positive; used is a finding.
• Day 3: assemble the contract file. Pull the LIUM edition matching each release, the OAA/OSG Licensing Change FAQ, and the 5 December 2019 Oracle blog post. Store them with retrieval dates. Oracle's public documentation changes; your archived copy does not.
• Days 4 to 5: map contract vintage to entitlement. For each ordering document, record whether Spatial is described as a priced option. Pre-2019 unrestated contracts on legacy releases are where a $17,500 per processor claim lives, and it applies to every processor under the database, not just the ones running spatial queries.
• Day 6: decide remediation or written confirmation. Where usage is genuinely zero, remove the component and document the change ticket. Where usage is real on a legacy release, seek written entitlement confirmation from your account team, in email, before anyone from Oracle asks a question.
• Day 7: brief the single point of contact. One named person answers Oracle. Everyone else forwards. Our audit-response playbook and the wider database options and packs guidance explain why scripted answers beat helpful ones.

The highest-value action in that list is day six. Get the entitlement in writing before an audit letter arrives. Afterward, the same sentence costs you a purchase order.

Related reading: Oracle Locator vs Spatial: Which Features Are Free and Which Trigger a Bill.

Frequently asked questions

Is Oracle Spatial free now?

Since 5 December 2019, Spatial and Graph functionality is included with the underlying Oracle Database license for Enterprise Edition, Standard Edition 2, Personal Edition and all Oracle Database Cloud Service editions, at database version 11.2 and higher, provided your support contract is active. It is no longer a separately priced option and no longer appears on the price list. The exception is contractual: if your ordering document and its program documentation describe Spatial and Graph as a purchasable option, Oracle auditors can still raise it, so obtain written confirmation rather than relying on the announcement alone.

What did Oracle Spatial and Graph cost before the change?

Immediately before 5 December 2019, the option listed at $17,500 per Processor and $350 per Named User Plus for Enterprise Edition. Like every database option, it had to be licensed on the same metric and the same quantity as the database beneath it, so a 16-processor database using Spatial in one schema required 16 processors of the option. Backdated support at 22 percent is what turns a modest list figure into a seven-figure claim.

Why does Oracle's audit script report Spatial usage when we only use Locator?

Oracle's options_packs_usage_statistics.sql reads DBA_FEATURE_USAGE_STATISTICS, and Oracle has documented known defects in that view under MOS Doc ID 1309070.1, including false positives that report Spatial usage where only Locator is in use. The specific reference worth quoting in writing is Bug 25661076, which records that DBA_FEATURE_USAGE_STATISTICS incorrectly shows Spatial usage in 12c. Oracle's own script disclaimer states the statistics are informational only and do not represent any license entitlement or requirement.

What is the difference between Oracle Locator and Oracle Spatial?

On releases up to 18c, Locator shipped free with every edition and provided SDO_GEOMETRY data types, spatial operators, spatial indexing and a limited subprogram set. The priced Spatial and Graph option added linear referencing, GeoRaster, Topology, Network Data Model, Geocoder, routing, spatial analytic functions, web services and 3D support. From 19c onward, Oracle's own Developer's Guide states there is no distinction between the two, and Locator users are told to move to the full feature set because no extra-cost license is required.

Does using Oracle Spatial give us the Partitioning option?

No. The Licensing Information User Manual grants only a restricted-use license to Partitioning where it is required by Spatial functionality, not a general Partitioning entitlement. If your DBAs partition non-spatial tables on the same database, that is full Partitioning use and it is separately licensable at list. Treat restricted-use grants as narrow and document exactly which objects rely on them.

Does Spatial work the same way on Standard Edition 2?

The entitlement is the same, but the execution is not. Standard Edition 2 does not support parallel operations, so Spatial functions run serially, and Oracle noted at the time of the change that SE2 support depended on a forthcoming update and may require an additional patch. Size any SE2 spatial workload on SE2 hardware and SE2 behaviour, never on Enterprise Edition benchmarks, or you will discover the performance gap in production.