{"id":3274,"date":"2026-09-08T21:08:00","date_gmt":"2026-09-09T02:08:00","guid":{"rendered":"https:\/\/bijoos.com\/oraclenotes\/?p=3274"},"modified":"2026-09-08T20:59:28","modified_gmt":"2026-09-09T01:59:28","slug":"oracles-base-database-service-changes-for-oci-deployments","status":"publish","type":"post","link":"https:\/\/bijoos.com\/oraclenotes\/2026\/3274\/","title":{"rendered":"Oracle&#8217;s Base Database Service Changes for OCI Deployments"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">If you run Oracle databases on OCI, July 2026 was a significant inflection point that deserves more than a passing glance at your email inbox. Oracle retired several Base Database Service configurations and billing SKUs, made architectural changes to what new VM.BaseDB.x86 deployments can do, and pointed workloads that depended on those capabilities toward a different service tier. Understanding these changes before you provision your next database (or renew an existing contract) can save you from a performance surprise or an unexpected migration.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This post walks through what changed, why the OCPU-to-ECPU transition is trickier than it looks, what exception paths Oracle has provided for teams that cannot move immediately, and how to decide whether Base Database or Exascale is the right landing zone for your workload.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><strong>What Changed at the Architecture Level<\/strong><\/h4>\n\n\n\n<p class=\"wp-block-paragraph\">Oracle&#8217;s Base Database Service on VM.BaseDB.x86 shapes has always been the go-to option for departmental and mid-tier Oracle databases on OCI: managed-platform, cost-effective, and familiar. But new deployments on this shape now look different from what many teams have been running.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>ASM is gone for new systems.<\/strong> Oracle Automatic Storage Management is no longer an option for new VM.BaseDB.x86 DB Systems. These systems now use Logical Volume Manager (LVM) with OCI Block Volume as the underlying storage. For many workloads this is perfectly fine: OCI Block Volume is durable, snapshottable, and performs well at typical departmental workload profiles. But teams that tuned their systems around ASM&#8217;s failure groups, disk group redundancy, or fine-grained I\/O balancing will need to revisit those assumptions. LVM on Block Volume is not ASM; the operational model is different.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Storage resize is a practical example of that difference. Expanding storage is online under both, but the similarity ends there. ASM rebalances automatically in the background with no manual intervention. On LVM with OCI Block Volume, you work through the OCI console resize, a block device rescan, pvresize, lvextend, and a filesystem grow command; the database stays up, but it is a manual, step-by-step process. Shrinking storage is the starker gap: ASM disk group reduction is an online, fully automated operation. OCI Block Volume cannot be reduced in size at all, and LVM&#8217;s lvreduce requires the filesystem to be unmounted first. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Two-node RAC is gone for new systems.<\/strong> New VM.BaseDB.x86 DB Systems are single-node only. If your requirement includes a clustered database (high availability through Oracle RAC), this shape no longer serves that need for new deployments. Existing two-node RAC systems on eligible legacy shapes can continue to run, but you cannot provision a new one here.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><strong>What Oracle Retired as of July 31, 2026<\/strong><\/h4>\n\n\n\n<p class=\"wp-block-paragraph\">Beyond the architectural constraints, Oracle formally retired the following:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>VM.Standard.x86 shape<\/strong>, the predecessor to VM.BaseDB.x86 for database workloads<\/li>\n\n\n\n<li><strong>Enterprise Edition \u2013 Extreme Performance<\/strong> on Base Database VM shapes<\/li>\n\n\n\n<li><strong>All OCPU-metered Base Database Service SKUs<\/strong><\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Existing deployments are not force-migrated; they can continue to run under their current configurations. But new provisioning is affected immediately, and contract renewals are affected as well. If you are coming up on a renewal for an Extreme Performance deployment, you need to understand that the path forward is not a simple SKU swap.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Oracle&#8217;s stated direction is:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>VM.BaseDB.x86 with ECPU-based billing<\/strong> for supported single-instance Base Database workloads<\/li>\n\n\n\n<li><strong>Oracle Exadata Database Service on Exascale Infrastructure (ExaDB-XS)<\/strong> for workloads that previously depended on Enterprise Edition Extreme Performance: the high I\/O, in-memory, and RAC capabilities that made Extreme Performance the right choice for demanding OLTP and analytics<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">If your current deployment is on Extreme Performance because of genuine workload requirements (database in-memory, active data guard, or HA through RAC), the migration path is Exascale, not the new Base Database edition.<\/p>\n\n\n\n<h5 class=\"wp-block-heading\"><strong>A Note on Continuity Options<\/strong><\/h5>\n\n\n\n<p class=\"wp-block-paragraph\">Before committing to an immediate migration, it is worth understanding what Oracle has communicated around continuity. None of this is an official guarantee, and terms will vary by customer and contract, but these are the paths that have been discussed.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>For OCPU shapes and ASM:<\/strong> Customers who cannot immediately move off OCPU billing or ASM have been advised to engage Oracle Support. Oracle has indicated a willingness to work with customers on a case-by-case basis, though outcomes are not guaranteed.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>For Enterprise Edition Extreme Performance:<\/strong> Customers seeking to continue EE-EP capabilities should engage their Oracle account team directly.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Migration timeline:<\/strong> Oracle has committed to a minimum of 12 months&#8217; notice before any forced migration. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><em>These continuity options are not permanent solutions and should not be treated as a substitute for an architecture review. Use any additional time to plan the migration properly.<\/em><\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><strong>The OCPU-to-ECPU Transition: Where Teams Get Tripped Up<\/strong><\/h4>\n\n\n\n<p class=\"wp-block-paragraph\">The move from OCPU-based to ECPU-based billing is where I see the most potential for a silent performance regression, and it is worth taking time to understand the math.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>The conversion rate is 1 OCPU = 4 ECPU.<\/strong> That sounds straightforward, but the memory allocation behind it is where things get complicated.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Under the prior AMD E4\/E5-based OCPU shapes, each OCPU came with 16 GB of RAM. Under VM.BaseDB.x86 with ECPU billing, you get 8 GB of RAM for every 4 ECPUs.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Run those numbers on a real example:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><td><strong>Configuration<\/strong><\/td><td><strong>CPU Units<\/strong><\/td><td><strong>RAM Available<\/strong><\/td><td><strong>vs. Old Shape<\/strong><\/td><\/tr><tr><td>Old: AMD E4\/E5 OCPU shape<\/td><td>4 OCPU (= 16 ECPU)<\/td><td>64 GB (16 GB\/OCPU)<\/td><td>baseline<\/td><\/tr><tr><td>New: VM.BaseDB.x86 ECPU<\/td><td>16 ECPU<\/td><td>32 GB (8 GB \/ 4 ECPUs)<\/td><td><strong>-50%<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">A database that ran on 4 OCPUs had 64 GB of RAM. The equivalent 16-ECPU shape delivers 32 GB, half as much. This is not a rounding error; it is a halving of available memory at an equal ECPU count, and Oracle databases are extremely memory-sensitive.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Why does this matter so much for Oracle databases specifically? <\/strong>Because SGA and PGA are the first things to suffer. Your buffer cache, shared pool, and in-memory area are all drawn from SGA. A smaller SGA means more physical reads, more latching, and more contention under load. A database that ran cleanly on the old shape can behave very differently if memory is constrained after migration.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The right approach is to size for both CPU and memory, then pick the shape that satisfies the more demanding constraint. Review your current SGA\/PGA configuration: the V$SGA and V$PGASTAT views, AWR memory statistics, and your memory_target or sga_target parameters. Make sure the new shape provides enough headroom before you finalize sizing. A direct OCPU-to-ECPU conversion is not safe.<\/p>\n\n\n\n<h5 class=\"wp-block-heading\"><strong>What the Move Actually Costs: OCPU vs. ECPU vs. Exascale<\/strong><\/h5>\n\n\n\n<p class=\"wp-block-paragraph\">The table below shows the all-in monthly cost for the same workload profile across all three tiers: 4 OCPU (old) or equivalent 16 ECPU (new), 2,000 GB storage, 730 hours at pay-as-you-go list prices. Each total includes block storage costs at high performance (20 VPU) or Exa storage.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><td><strong>Edition<\/strong><\/td><td><strong>Old: Base DB (OCPU)<\/strong><\/td><td><strong>New: Base DB (ECPU)<\/strong><\/td><td><strong>Change<\/strong><\/td><td><strong>Exascale (ExaDB-XS)<\/strong><\/td><\/tr><tr><td>BYOL<\/td><td>$684\/mo<\/td><td>$1,098\/mo<\/td><td><strong>+61%<\/strong><\/td><td>$1,799\/mo<\/td><\/tr><tr><td>Enterprise<\/td><td>$1,375\/mo<\/td><td>$1,789\/mo<\/td><td><strong>+30%<\/strong><\/td><td>n\/a<\/td><\/tr><tr><td>High Performance<\/td><td>$2,709\/mo<\/td><td>$3,124\/mo<\/td><td><strong>+15%<\/strong><\/td><td>n\/a<\/td><\/tr><tr><td>Extreme Performance<\/td><td>$4,044\/mo<\/td><td>Not available<\/td><td>n\/a<\/td><td>$4,781\/mo (+18%)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\"><em>Storage included in each total: OCPU uses OCI Block Volume ($119\/mo for 2,000 GB); ECPU uses Oracle Base Database Storage ($240\/mo); Exascale uses Smart Database Storage plus VM Filesystem ($419\/mo). ECPU totals also include the $0.0251\/ECPU\/hr compute infrastructure charge ($293\/mo at 16 ECPUs).<\/em><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A few observations worth calling out. The BYOL increase is the sharpest at 61% because the flat compute infrastructure charge ($293\/month) is a larger fraction of a lower starting cost. The Extreme Performance migration to Exascale looks like a relatively modest 18% increase, but that comparison is not straightforward: Exascale storage is Smart Database Storage, a fundamentally different tier from Block Volume, with Exadata Smart Scan and storage offloading. A workload that runs on Exascale storage typically needs a smaller SGA than the same workload on Block Volume, which partially offsets the memory difference between the tiers. The storage cost premium is real, but it is not purely overhead.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><strong>Bill of Materials Reference<\/strong><\/h4>\n\n\n\n<p class=\"wp-block-paragraph\">The three tables below show the individual Oracle part numbers and unit prices that make up each model. Config basis: 4 OCPU \/ 16 ECPU, 2,000 GB storage, 730 hours\/month, pay-as-you-go list price. DBCS EE-EE to Exascale is a no-brainer. Review DBCS vs. Exascale for all other deployments, especially if you have an opportunity to consolidate databases on Exascale. For example, many EBS customers provision one DB System for each environment because the DBCS VM can have only one CDB and EBS does not support more than one PDB per CDB. In the Exascale model, you can consolidate non-prod databases into a single system. <\/p>\n\n\n\n<h5 class=\"wp-block-heading\"><strong>Base Database Service: OCPU Model<\/strong><\/h5>\n\n\n\n<figure class=\"wp-block-image size-large\"><a href=\"https:\/\/i0.wp.com\/bijoos.com\/oraclenotes\/wp-content\/uploads\/2026\/09\/image.png?ssl=1\" target=\"_blank\" rel=\" noopener\"><img data-recalc-dims=\"1\" loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"278\" src=\"https:\/\/i0.wp.com\/bijoos.com\/oraclenotes\/wp-content\/uploads\/2026\/09\/image.png?resize=1024%2C278&#038;ssl=1\" alt=\"\" class=\"wp-image-3275\" srcset=\"https:\/\/i0.wp.com\/bijoos.com\/oraclenotes\/wp-content\/uploads\/2026\/09\/image.png?resize=1024%2C278&amp;ssl=1 1024w, https:\/\/i0.wp.com\/bijoos.com\/oraclenotes\/wp-content\/uploads\/2026\/09\/image.png?resize=300%2C81&amp;ssl=1 300w, https:\/\/i0.wp.com\/bijoos.com\/oraclenotes\/wp-content\/uploads\/2026\/09\/image.png?resize=767%2C208&amp;ssl=1 767w, https:\/\/i0.wp.com\/bijoos.com\/oraclenotes\/wp-content\/uploads\/2026\/09\/image.png?w=1497&amp;ssl=1 1497w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/a><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\"><em>Note: Each OCPU gets 16 GB of RAM.<\/em><\/p>\n\n\n\n<h5 class=\"wp-block-heading\"><strong>Base Database Service: ECPU Model<\/strong><\/h5>\n\n\n\n<figure class=\"wp-block-image size-large\"><a href=\"https:\/\/i0.wp.com\/bijoos.com\/oraclenotes\/wp-content\/uploads\/2026\/09\/image-1.png?ssl=1\" target=\"_blank\" rel=\" noopener\"><img data-recalc-dims=\"1\" loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"253\" src=\"https:\/\/i0.wp.com\/bijoos.com\/oraclenotes\/wp-content\/uploads\/2026\/09\/image-1.png?resize=1024%2C253&#038;ssl=1\" alt=\"\" class=\"wp-image-3276\" srcset=\"https:\/\/i0.wp.com\/bijoos.com\/oraclenotes\/wp-content\/uploads\/2026\/09\/image-1.png?resize=1024%2C253&amp;ssl=1 1024w, https:\/\/i0.wp.com\/bijoos.com\/oraclenotes\/wp-content\/uploads\/2026\/09\/image-1.png?resize=300%2C74&amp;ssl=1 300w, https:\/\/i0.wp.com\/bijoos.com\/oraclenotes\/wp-content\/uploads\/2026\/09\/image-1.png?resize=764%2C189&amp;ssl=1 764w, https:\/\/i0.wp.com\/bijoos.com\/oraclenotes\/wp-content\/uploads\/2026\/09\/image-1.png?w=1496&amp;ssl=1 1496w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/a><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\"><em>Note: Each infrastructure ECPU gets 2 GB of RAM. B112724 (infrastructure charge) is a separate line item, but we can&#8217;t increase the ECPU to allocate more RAM. Maybe it is a feature coming in the future. <\/em>B111584 (storage) is now one SKU that includes block storage and performance units.<em> Extreme Performance is not available on the ECPU Base Database shape. <\/em><\/p>\n\n\n\n<h5 class=\"wp-block-heading\"><strong>Exadata Database Service on Exascale Infrastructure (ExaDB-XS)<\/strong><\/h5>\n\n\n\n<figure class=\"wp-block-image size-large\"><a href=\"https:\/\/i0.wp.com\/bijoos.com\/oraclenotes\/wp-content\/uploads\/2026\/09\/image-2.png?ssl=1\" target=\"_blank\" rel=\" noopener\"><img data-recalc-dims=\"1\" loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"248\" src=\"https:\/\/i0.wp.com\/bijoos.com\/oraclenotes\/wp-content\/uploads\/2026\/09\/image-2.png?resize=1024%2C248&#038;ssl=1\" alt=\"\" class=\"wp-image-3277\" srcset=\"https:\/\/i0.wp.com\/bijoos.com\/oraclenotes\/wp-content\/uploads\/2026\/09\/image-2.png?resize=1024%2C248&amp;ssl=1 1024w, https:\/\/i0.wp.com\/bijoos.com\/oraclenotes\/wp-content\/uploads\/2026\/09\/image-2.png?resize=300%2C73&amp;ssl=1 300w, https:\/\/i0.wp.com\/bijoos.com\/oraclenotes\/wp-content\/uploads\/2026\/09\/image-2.png?resize=765%2C185&amp;ssl=1 765w, https:\/\/i0.wp.com\/bijoos.com\/oraclenotes\/wp-content\/uploads\/2026\/09\/image-2.png?w=1496&amp;ssl=1 1496w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/a><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\"><em>Note: Each ECPU gets 2.75 GB of RAM. Unlike DBCS, here we are allowed to choose a higher ECPU count for B109355 (RDMA infrastructure) to allocate more RAM. Smart Storage is Exadata-tier (Smart Scan, storage offloading), not OCI Block Volume.<\/em><\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><strong>How to Migrate: Paths Oracle Supports<\/strong><\/h4>\n\n\n\n<p class=\"wp-block-paragraph\">Oracle has documented specific migration paths depending on where you are starting from. These are the supported options per KB921246:<\/p>\n\n\n\n<h5 class=\"wp-block-heading\"><strong>VM.Standard.x86 (ECPU) \u2192 VM.BaseDB.x86 (ECPU)<\/strong><\/h5>\n\n\n\n<p class=\"wp-block-paragraph\">The simplest path. For DB Systems currently on the retired VM.Standard.x86 shape, Oracle provides a &#8220;Change Shape&#8221; button directly in the OCI console. This is an in-place shape change and does not require data movement or a new provisioning exercise. Use this when the destination configuration (single-node, LVM) meets your requirements.<\/p>\n\n\n\n<h5 class=\"wp-block-heading\"><strong>OCPU-Metered \u2192 ECPU-Metered (Single Instance)<\/strong><\/h5>\n\n\n\n<p class=\"wp-block-paragraph\">For moving from OCPU billing to ECPU billing on single-instance databases, Oracle supports two approaches:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Zero Downtime Migration (ZDM):<\/strong> Oracle&#8217;s ZDM utility automates the data movement and cutover, minimizing downtime. <\/li>\n\n\n\n<li><strong>Standby + Switchover:<\/strong> Create a physical standby on the new ECPU-metered shape, validate it, then perform a controlled switchover. This is a manual approach but gives you full control.<\/li>\n<\/ul>\n\n\n\n<h5 class=\"wp-block-heading\"><strong>Enterprise Edition Extreme Performance \u2192 Exascale (ExaDB-XS)<\/strong><\/h5>\n\n\n\n<p class=\"wp-block-paragraph\">Workloads that genuinely required Extreme Performance capabilities (Oracle Database In-Memory, high-throughput I\/O, or RAC) move to Oracle Exadata Database Service on Exascale Infrastructure. The same migration tooling applies: ZDM for automated migration, or a Standby + Switchover approach for environments where you want extended parallel running before cutover.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Note that ExaDB-XS is a substantively different service tier, not a renamed Base Database edition. The pricing model, feature set, and operational characteristics are all different. If you are evaluating this path, engage your OCI partner early; the architecture review takes more than a weekend.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><strong>How to Decide: Base Database or Exascale?<\/strong><\/h4>\n\n\n\n<p class=\"wp-block-paragraph\">With the architecture changes and retirements now visible, the decision tree is clearer than it might have been before.<\/p>\n\n\n\n<h5 class=\"wp-block-heading\"><strong>Stay with Base Database (VM.BaseDB.x86, ECPU) if:<\/strong><\/h5>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Your workload is a single Oracle Database instance with no RAC requirement<\/li>\n\n\n\n<li>You can live with LVM on Block Volume (no deep ASM dependency)<\/li>\n\n\n\n<li>Your memory footprint fits the 8 GB per 4-ECPU ratio at your required core count<\/li>\n\n\n\n<li>You are running Standard Edition or Enterprise Edition without the Extreme Performance features<\/li>\n\n\n\n<li>You have an existing Oracle Database license (BYOL) and want the most economical managed database option<\/li>\n<\/ul>\n\n\n\n<h5 class=\"wp-block-heading\"><strong>Move to Exascale if:<\/strong><\/h5>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Your workload requires Enterprise Edition Extreme Performance: RAC, high-throughput I\/O, or Database In-Memory option<\/li>\n\n\n\n<li>Your I\/O profile demands consistent, predictable storage performance that Block Volume alone does not satisfy<\/li>\n\n\n\n<li>You were on an Extreme Performance renewal path and that path is now closed on Base DB shapes<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">One subtlety worth noting: Exascale is not simply &#8220;more expensive Base Database.&#8221; It is a different architecture: Exadata-derived storage, Smart Scan, storage offloading, and the Exascale storage tier. The feature set is substantially broader. Whether the cost delta is justified depends entirely on whether your workload needs those features. Going to Exascale for a departmental single-instance database to avoid the Base DB changes is almost certainly oversized.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><strong>What You Should Be Doing Right Now<\/strong><\/h4>\n\n\n\n<p class=\"wp-block-paragraph\">If you manage Oracle databases on OCI, the following actions are not optional:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Audit your existing deployments for legacy shapes and SKUs.<\/strong> Identify any VMs on VM.Standard.x86 or any systems with OCPU-based contracts. Understand when those contracts come up for renewal.<\/li>\n\n\n\n<li><strong>Flag your Extreme Performance deployments.<\/strong> These are the highest-risk for a forced change at renewal. Map each one to a replacement option now; do not leave this for the renewal conversation.<\/li>\n\n\n\n<li><strong>Do not size new ECPU deployments by CPU alone.<\/strong> Pull AWR or Statspack data from each source database and note the SGA and PGA targets. The correct ECPU count is the one that satisfies your memory requirement, not the one that matches your OCPU count.<\/li>\n\n\n\n<li><strong>Validate LVM storage for your workloads.<\/strong> If you have storage tuning based on ASM disk groups, NORMAL or HIGH redundancy, or disk group rebalancing behavior, test the LVM on Block Volume behavior in a non-production environment before committing.<\/li>\n<\/ol>\n\n\n\n<h4 class=\"wp-block-heading\"><strong>Closing Thoughts<\/strong><\/h4>\n\n\n\n<p class=\"wp-block-paragraph\">Oracle&#8217;s direction here is not arbitrary. The shift toward ECPU simplifies the billing model and aligns with how modern cloud resources are actually consumed (also, memory chips are in demand and costs skyrocketed). Eliminating Extreme Performance from Base DB shapes reflects clearer product stratification: managed, cost-efficient single-instance databases on one end, Exadata-class performance with Exascale on the other, and less ambiguity in between.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">What it means for practitioners is a need for deliberate architecture review on any database that was provisioned before mid-2026 or that is due for a configuration change. Oracle is not forcing anyone into a hard cutover overnight, but the continuity options are a bridge, not a destination.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If you are sizing a new deployment or evaluating a renewal, take the time to do the memory arithmetic, assess whether single-node LVM is appropriate, and make a conscious call on whether Base Database or Exascale is the right tier. The answers will be specific to your workload; there is no universal correct answer.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If you have questions about specific configurations or want to compare numbers for your workload, leave a comment or reach me directly.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>If you run Oracle databases on OCI, July 2026 was a significant inflection point that deserves more than a passing glance at your email inbox. Oracle retired several Base Database Service configurations and billing SKUs, made architectural changes to what new VM.BaseDB.x86 deployments can do, and pointed workloads that depended on those capabilities toward a &#8230; <a title=\"Oracle&#8217;s Base Database Service Changes for OCI Deployments\" class=\"read-more\" href=\"https:\/\/bijoos.com\/oraclenotes\/2026\/3274\/\" aria-label=\"Read more about Oracle&#8217;s Base Database Service Changes for OCI Deployments\">Read more<\/a><\/p>\n","protected":false},"author":1,"featured_media":3278,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[4,133],"tags":[162,160,161,55],"class_list":["post-3274","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud-autonomous","category-oracledb","tag-base-database-service","tag-oci-db-system","tag-oci-exascale","tag-oracle-cloud"],"acf":[],"jetpack-related-posts":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/i0.wp.com\/bijoos.com\/oraclenotes\/wp-content\/uploads\/2026\/09\/oci-base-db-header.png?fit=1200%2C400&ssl=1","_links":{"self":[{"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/posts\/3274","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/comments?post=3274"}],"version-history":[{"count":4,"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/posts\/3274\/revisions"}],"predecessor-version":[{"id":3284,"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/posts\/3274\/revisions\/3284"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/media\/3278"}],"wp:attachment":[{"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/media?parent=3274"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/categories?post=3274"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/tags?post=3274"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}