Almost every office has a fire extinguisher. Far fewer have one mounted properly, charged to pressure, and inspected on a schedule. Security controls are no different. Owning a control and operating one are different problems, and the latter is where security programs more often fail.
That gap is widest at sites with no dedicated database administrator, let alone a database security specialist. The same pattern repeats across branch and satellite offices running local databases for latency, connectivity, or regulatory reasons. Add sites and the number of databases needing supervision grows; the number of people supervising them does not.
These are the buyers Oracle is targeting with the new Base Database Cloud@Customer, announced as a mid-scale hybrid cloud tier below Exadata Cloud@Customer, which is designed for large-scale, mission-critical workloads.
Mounted on Arrival: What the Cloud Connection Buys
Base Database Cloud@Customer occupies roughly the position Oracle Database Appliance held for years, serving mid-scale Oracle workloads at customer locations. The hardware is conventional, two X11 servers in an 8U footprint, up to 120 usable cores, and 47.2 TB of all-flash storage at the top end. The infrastructure subscription runs four years minimum, with an optional fifth, while compute and storage scale online. You commit on the hardware and adjust the licensing later, the reverse of most on-premises purchases.
A more important difference is that Oracle Database Appliance had no cloud connection, and this platform does. That connection is how Oracle ships the security controls already configured instead of leaving them for you to set up. Oracle owns and operates the servers, storage, network, hypervisor, firmware, and system software. Nobody at the site needs to know how to build a correctly configured database platform.
Cloud automation encrypts data across the databases, enforces password policies, and manages backups, Data Guard configuration, and Real Application Clusters (RAC) failover. All of it runs through a management layer in Oracle Cloud Infrastructure (OCI) that reaches the on-premises system over a secure tunnel.
Bring Your Own License (BYOL) deployments of both Oracle AI Database Enterprise Edition and Standard Edition on Base Database Cloud@Customer include Transparent Data Encryption (TDE) and Oracle Data Safe at no additional license cost. Databases using the license-included consumption model include all Oracle AI Database security options and management packs supported for that edition, also at no additional cost.
With AI agents now querying these databases too, that coverage matters more, and Oracle Key Vault extends it: an on-premises appliance that keeps the master key on your site but outside the database virtual machine holding the data.
Patching Gets Dramatically Easier: Up to the Database Line
Oracle manages this platform, but it does not patch all of it: that would be Autonomous AI Database on Exadata Cloud@Customer. With Base Database Cloud@Customer, Oracle patches the hypervisor, system software, and firmware across the infrastructure it owns, within a maintenance window you can adjust to fit your own operating requirements. The guest operating system and the database remain yours to schedule.
That work runs through cloud automation, which removes the standard reasons for postponing a patch. Rolling updates across a two-server RAC configuration turn zero-downtime patching from a quarterly infrastructure project into a routine operation.
What the automation cannot do is decide when to update the database. The platform will not catch a missed database patch, and the deferrable infrastructure window has no equivalent on the database side. The practical question at these sites is whether anyone owns the schedule.
Private AI On Site: Protection at the Data Layer
Oracle positions the service as “private AI for data, anywhere.” The same infrastructure can run Oracle Private AI Services Container with local open-weight models alongside Oracle AI Database Private Agent Factory, so embedding generation, vector storage, and retrieval-augmented generation all happen behind your firewall.
Data residency requirements, sector-specific regulations, and emerging AI governance obligations all turn on where processing occurs, who can reach it, and whether you can demonstrate both to an auditor. Keeping all of it inside one physical boundary answers those questions more persuasively than a contractual assurance about a public cloud region.
One caveat: your data stays local, but the management layer does not, and some regulators ask about management residency separately from data residency. If the management link drops, your databases keep running, so this is a governance question rather than an availability one.
Local infrastructure gives you guardrails you can inspect and control. The durable protection sits one layer down, next to the data, where a control holds regardless of what is asking and cannot be switched off by whoever runs the model. Stopping an agent from dropping a production table needs no AI security product, only a privilege model under which nothing, human or agent, holds that entitlement.
That is the model Oracle already applies by placing enforcement in the data layer, and Base Database Cloud@Customer brings it within reach of organizations that could not previously operate it. That enforcement lives in Deep Data Security, new in Oracle AI Database 26ai, and in the in-database SQL Firewall, and both are worth enabling at provisioning time: a control you switch on after your first incident did not protect you from it.
Inspection Is Still Yours
You hold root access to the database virtual machines and full DBA privileges on the databases you provision. Controls that arrive running can stop running later, switched off during a troubleshooting session that nobody reverted, or lost when a database is rebuilt without its policies. Encryption status, audit configuration, and agent privileges need checking on a recurring schedule, because none of them announce it when they change.
Oracle has removed the price barrier earlier, and now most of the deployment barrier as well through cloud automation. The controls arrive running, the platform is operated for you, and sites without a database specialist now get a security posture that used to require one. The fire extinguisher arrives mounted and charged. Checking the gauge is still your job, unless, of course, you opt for Autonomous AI Database on Exadata Cloud@Customer.