GIS workloads break the standard Named User Plus math because map portals, sensor feeds, and connection pools make the user count either unknowable or far larger than headcount. This guide shows where the metric decision actually sits for a spatial estate and how to avoid paying twice for a feature Oracle now bundles.
GIS workloads break the standard Named User Plus math because map portals, sensor feeds, and connection pools make the user count either unknowable or far larger than headcount. This guide shows where the metric decision actually sits for a spatial estate and how to avoid paying twice for a feature Oracle now bundles.
The single most important fact for any GIS estate is that Oracle Spatial is no longer a paid option on current releases. As of December 5, 2019, the Spatial and Graph features of Oracle Database may be used for development and deployment with all on-premises editions and Oracle Cloud Database Services, with no additional license required. That means for a modern Enterprise Edition or Standard Edition 2 estate, the spatial workload does not carry the historical $17,500 per processor charge. The metric decision is therefore not about Spatial as a separate line item. It is about the underlying Database license that the spatial workload runs on.
Two carve-outs survive. First, Oracle Graph Server and Studio is a separately licensed product, so property graph work is not free. Second, certain advanced spatial features in Oracle Autonomous Database carry additional charges, which we treat separately in the cloud cost comparison. For the on-premises GIS estate, though, the practical exposure is the Database EE or SE2 license underneath, plus the risk that you are on an older release where the bundling change was never reflected in your ordering documents. We cover that release-specific trap in the Spatial and Graph pillar guide.
Contractual caution: the contractually binding 19c program documentation says Spatial and Graph is included, but only for that version. Program documentation for earlier versions was not updated, so on a purely contractual reading, an organization running 12c or 18c cannot simply assume an included license from a blog post. Blog posts are not contract paper. Verify your specific ordering documents before you rely on the bundling. In our negotiating experience, Oracle rarely presses this point on customers already current on support and running 19c or later, but on older releases it is live leverage that a licensing manager should neutralize proactively rather than discover in an audit.
Oracle prices the same Database license two ways. On the Technology Global Price List effective April 16, 2026, Enterprise Edition lists at $47,500 per Processor and $950 per Named User Plus. Oracle sets NUP at exactly one fiftieth of the Processor price on every Database line. That is deliberate. It fixes the arithmetic crossover at 50 real users per Processor, floors permitting. Below 50 countable users per Processor, NUP is cheaper. Above 50, Processor wins. This is the core mechanic explained in full on our Named User Plus or Processor metric decision page.
The word that decides everything for GIS is countable. The floors and the counting rules, not the raw arithmetic, are what determine whether NUP is even legal for your workload. EE carries a 25 NUP per Processor floor. SE2 carries a 10 NUP per server floor. You license the higher of the floor and your real, enumerated headcount. Options follow the base metric: if Database is licensed per Processor, everything on it is per Processor. And you cannot mix metrics on a single deployment. A cluster or shared environment goes entirely Processor or entirely NUP.
| Metric | EE list (per unit) | Support (22%) | Floor rule | Best fit for GIS |
|---|---|---|---|---|
| Processor | $47,500 | $10,450 | None (core factor applies) | Public map portals, unknown user counts, sensor feeds |
| Named User Plus | $950 | $209 | 25 NUP per Processor (EE) | Small internal GIS teams with fully enumerable users |
Oracle fixed the crossover at 50 users per Processor. For a GIS estate the real question is whether your users can be counted at all, not whether you have 49 or 51 of them.
NUP is unavailable for any environment where users cannot be counted. Oracle's definitions are explicit: web-facing portals, multi-tenant SaaS, and any third-party application where the user population is not knowable cannot be licensed by Named User Plus. This is not a soft preference. Audit findings frequently reclassify NUP deployments as Processor deployments the moment this restriction is violated, and the reclassification is where the money is.
A public map portal is the textbook disqualifier. If your spatial database serves an internet-facing map viewer, a parcel lookup tool, or any B2B geospatial integration where the population is large, unknown, or unlimited, Processor is almost always the only defensible metric. Trying to run that on NUP is not saving money, it is deferring a much larger bill to the day an LMS auditor asks how you enumerate anonymous public users. In our experience, this is the single most common way a GIS estate walks into a seven-figure finding: an internal team licensed the database on NUP years ago, then the mapping application went public and nobody re-examined the metric.
GIS architectures are built on middle tiers. A map server, a tile cache, a feature service, a connection pool. Buyers routinely assume that because only the application service connects to Oracle, they only need to count that service. Oracle's multiplexing rule says the opposite. If multiplexing hardware or software (for example a TP monitor or a web server product) is used, the user count must be measured at the multiplexing front end. In plain terms, a map server or a pooled connection does not collapse ten thousand end users into one Oracle account. You count the end users at the front end.
Indirect access carries the same rule. When a GIS front end connects to Oracle on behalf of users without a separate multiplexing license, each end user still requires a NUP, or the deployment requires Processor licensing. This is why an internal team of 40 analysts can quietly become an untenable NUP count once their tools front a wider workforce or an external audience. The multiplexing tier is the trap, not the shield. If you cannot enumerate everyone behind the front end, you are on Processor whether you like it or not.
A connection pool that shows Oracle one login is invisible to the license. Oracle counts the humans and devices behind it, at the front end, every one.
Spatial estates increasingly ingest machine-generated location data: GPS fleet telematics, IoT sensors, drone imagery pipelines, SCADA feeds. Oracle's definition is unambiguous here too. A non-human operated device is counted as a Named User Plus in addition to all individuals authorized to use the programs, if such devices can access the programs. A GIS estate that streams from 2,000 fleet vehicles into an Oracle spatial database has 2,000 NUP obligations from the devices alone, before a single analyst is counted.
This device rule quietly settles the metric argument for most modern spatial pipelines. Any estate with meaningful machine-to-database ingest almost always crosses the 50-per-Processor crossover on devices alone, which pushes the economics toward Processor licensing regardless of how few humans use the system. Before you commit to NUP for a spatial workload, inventory every device that can reach the database. In our experience buyers consistently undercount this by an order of magnitude because devices are treated as data sources rather than users.
Choosing Processor solves the countability problem but introduces its own math. The processor count is physical cores multiplied by Oracle's core factor for that CPU type. A 16-core Intel server running Database EE lists at $380,000 in license plus $83,600 annual support. Support runs at 22 percent of net license fee on Premier Support. Note that nobody pays list. Enterprise customers typically negotiate 40 to 70 percent below list, and the discount you carry into a spatial workload should match the best discount already in your Oracle estate, not a fresh, worse number.
The larger Processor trap for GIS is virtualization. Map and imagery servers commonly sit on shared VMware clusters. VMware, Hyper-V, and most x86 virtual machine environments are treated by Oracle as soft partitioning and do not limit licensing scope. Organizations that deploy Oracle on a few vCPUs discover Oracle's policy requires licensing every physical core in the cluster. Worse, if the virtualization technology lets the database migrate between hosts, whether automatically via vMotion and DRS or manually, Oracle's position is that every physical host in the cluster where the database can run must be fully licensed.
There is a real counter-argument, and it is contractual. The signed agreement licenses processors where the programs are installed and running. Oracle's published virtualization positions sit outside the signed contract. They are policy documents, not contract paper. That does not make the risk disappear, but it does mean the exposure is negotiable and defensible, not automatic. The practical control is architectural: isolate spatial workloads onto dedicated hosts or an Oracle-approved hard partition so the licensable boundary is small and provable. We treat the VMware exposure in more depth across the metric decision guidance, and it should be modeled before any GIS consolidation onto shared infrastructure.
Even on releases where Spatial is bundled, the estate has a related exposure worth naming. Oracle's automatic feature tracking, DBA_FEATURE_USAGE_STATISTICS, captures every option ever used on every database, including a single test query that ran two years ago. The view retains usage history for the life of the database, and LMS auditors read it directly. For older releases where Spatial is not contractually included, a single developer experiment can register as spatial usage and become a finding. This is exactly the scenario covered in accidental Spatial enablement as an audit finding.
The defense is to know precisely which features you use and prove it. Many organizations run only Oracle Locator, the free subset, but cannot demonstrate they stay inside that line. The distinction matters and is drawn cleanly in the Locator versus Spatial feature comparison. If your estate is genuinely Locator-only, assemble the evidence pack now rather than under audit pressure, using the approach in the Locator-only defense guide.
The metric decision for a GIS estate is rarely close once you count correctly. Public map services and device feeds push almost every real spatial deployment past the 50-user crossover, which points to Processor. Where a small internal analyst team is the only population and every user is enumerable, NUP with the 25-per-Processor floor is cheaper. The mistake to avoid is licensing on NUP for a system that grows outward to the internet, then discovering the metric is invalid at exactly the moment Oracle is looking. Decide the metric against the fully counted population, not the headcount you notice.
On Oracle Database 19c and later, Spatial and Graph features are included at no additional cost with Enterprise Edition and Standard Edition 2, following the December 2019 bundling change. It still appears on the price list at $17,500 per processor, which is a legacy artifact. Graph Server and Studio remains separately licensed, and some Autonomous Database spatial features carry extra charges.
No. Named User Plus is unavailable for any environment where users cannot be counted, which explicitly includes web-facing portals. An internet-facing map service must be licensed by Processor. Audit findings routinely reclassify public-facing NUP deployments as Processor deployments, and that reclassification drives large back-license bills.
No. Oracle's multiplexing rule requires the user count to be measured at the multiplexing front end. A map server, tile service, or connection pool does not collapse many end users into one Oracle account. You count every human and device behind the front end.
Yes. Oracle counts each non-human operated device as a Named User Plus if it can access the database, in addition to all authorized individuals. A spatial estate ingesting from thousands of fleet vehicles or sensors often crosses the 50-per-processor crossover on devices alone, which pushes the economics toward Processor licensing.
Oracle prices NUP at one fiftieth of the Processor price, fixing the arithmetic crossover at 50 countable users per Processor, subject to the 25 NUP per Processor floor on Enterprise Edition. Below 50 enumerable users, NUP is cheaper; above 50, Processor wins. For GIS the deciding factor is usually whether users can be counted at all, not the exact number.
Query DBA_FEATURE_USAGE_STATISTICS, which records every option ever used for the life of the database, including one-off test queries. Reconcile that against the Locator feature boundary and assemble an evidence pack demonstrating you stay inside it. On older releases where Spatial is not contractually bundled, this reconciliation is your primary audit defense.
Oracle sells the same database per user and per processor. The 25 NUP per processor minimum, the 50 user break-even, and how to choose the metric that fits the workload.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
