The story published on October 20, 2026 was compelling. U.S. Bank, under a hard data-center-exit deadline, moved four management reporting databases from an on-premises Exadata system to Amazon RDS for Oracle. The migration was real, the numbers were public, and the engineering deserves credit. But the public write-up was, by its nature, a migration how-to. It told you how to leave and documented several adjustments along the way. It did not offer a full comparison of what you lose when you arrive, or what you could have kept if you had stayed on the same platform inside a different operating model.
I want to fill that gap. Just as a companion piece for the DBA or the architect who is now being asked the inevitable follow-up question: should we do the same? The answer is more layered than the headline, and the layers that matter are not about migration speed. They are about what Exadata service does that RDS does not, why those differences matter after the move and show up in the next quarter’s tuning logs, and where Oracle’s own presence inside AWS changes the arithmetic entirely.
This article has four parts. First, the high-availability gap, and why RAC clustering and standby failover are not the same thing. Second, the storage engine, where Smart Scan and Hybrid Columnar Compression live, and what losing them means for performance and cost. Third, the scalability ceiling, where the numbers are blunt and useful. Fourth, Oracle Database@AWS, which is the path that keeps the platform and gains the managed benefit, and which makes the binary choice of “leave or stay” a false one.
High availability and disaster recovery
This is a distinction that can get flattened in commercial comparisons and that needs to stand straight before anything else makes sense. Local clustering and remote failover are different things. They address different failure scenarios. They have different architectures. Confuse them, and you risk designing a system that passes a checklist and fails in production.
High availability is about what happens when a server fails inside your data center or your availability zone. The workloads running on it can continue on surviving servers. The aim is that users do not notice. The failover is automatic, measured in seconds, and transparent. In the Oracle world, that is Real Application Clusters (RAC) with Transparent Application Continuity (TAC). RAC runs a single database across multiple servers simultaneously. RAC runs a single database across multiple instances on different servers simultaneously. If one server fails, the surviving instances keep the database available without restarting the whole database. No interruption to the service. The database was never down. Only one server was. And we don’t need to duplicate data to have H.A.; all the instances are working with the same set of datafiles.
Disaster recovery is about what happens when the entire site, the availability zone, or the region goes away. The database resumes service somewhere else, from a copy whose data protection depends on the replication configuration. Data Guard provides both high availability and disaster recovery. A standby database (with it’s own set of datafiles) receives redo continuously from the primary and can assume the primary role through a controlled failover. The switch can be manual or automatic, but the standby does have to transition to the primary role to accept writes, even if it was already open read-only. Recovery can take seconds to minutes depending on the configuration, failure detection, redo to apply, and client reconnection. Data loss can be zero in an appropriate synchronous configuration.
The distinction matters because RDS for Oracle gives you disaster recovery but not actual high availability.
RDS Multi-AZ provisions a primary instance and a synchronous standby (duplicated set of datafiles) in a different availability zone. If the primary fails, the Multi-AZ mechanism detects the failure, promotes the standby, and repoints the DNS endpoint. That is disaster recovery: you have a copy, and when the primary is unavailable, you fail over to a different AZ. Now you have a this database in one AZ, and the app servers and related databases in the former AZ. This means an increase in latency, unless you activate all the resources on this new AZ; just because of 1 database failure.
Now compare that to an ExaDB-D@AWS system with RAC. Two – as a minimum – database servers run the same database. They are both in the same infrastructure, so they are in the same AZ. If one server fails, the other server is already running another instance of the database, keeping the session state. The surviving instance does not need to restart. The surviving node will keep working, and correctly configured services, clients, and AC or TAC can restore application work. SCAN helps clients locate those services. And the database is still running in the same AZ. That is high availability.
The difference is not academic. Small changes in application-to-database latency can matter. A hypothetical rise from 1ms to 7ms in an app server to DB connection can be a nightmare. Especially for a bank payment system, a trading platform, or a customer-facing service that expects sub-second response times. The RDS Multi-AZ model protects you against the loss of an entire availability zone, which is useful DR against that failure scenario. But recovery from a primary server failure still requires a failover. RAC provides another route for local failures and rolling maintenance: keep serving the database through instances that are already running in the same AZ.
Why does this matter in the context of a migration from Exadata? Because moving to RDS leaves the option of using RAC behind. RDS does not currently support RAC. It runs a single active Oracle instance for each database rather than spreading that database across active RAC instances. You can run it in Multi-AZ for disaster recovery, and for a production workload I would want that protection. But you are leaving behind RAC’s high availability. A failure of the primary server triggers a failover to another AZ within the same region. That is a fundamental change in the availability model of your database, and it is the kind of change that matters when an unplanned outage occurs.
The Oracle Maximum Availability Architecture, MAA, captures this layering explicitly. MAA Silver uses RAC for local high availability. MAA Gold adds Data Guard or Active Data Guard for data protection and rapid recovery from site failures, with automatic failover available through Fast-Start Failover. On an Exadata system, you can have both: RAC keeps the database available when a server fails, and Data Guard brings it back somewhere else when the site fails.
That is the high-availability gap. It is not a matter of opinion. It is a matter of architecture, and it is the first thing a DBA should put on the table when the migration question is asked. Especially in a banking production environment.
The storage engine does more than store
The second thing that Exadata does, that RDS does not, is harder to explain but easier to feel. It is the storage engine.
On a conventional database server, a simplified physical full scan works like this. The database process asks the operating system for blocks. The operating system asks the storage array for blocks. The storage array reads the blocks and sends them back up the stack. The blocks physically read for that scan travel to the database server, whether all their rows are needed for the final result or not. If you are scanning a billion-row table looking for the ten rows that match a filter on a non-indexed column, assuming no partition pruning or cached data avoids those reads, all billion rows come up from storage, through the I/O subsystem, to the database server for processing, and nine hundred and ninety-nine million nine hundred and ninety-nine thousand nine hundred and ninety of them are thrown away.
Exadata changes that. The Exadata storage servers are not dumb shelves of disks. They are computers running Oracle software. They understand Oracle blocks, Oracle predicates, and Oracle compression. When an eligible scan asks for rows where a column equals a particular value, the storage server can apply that filter before sending data to the database server. Matching rows and the required columns come up to the database server, reducing the data that leaves the storage tier. That is Smart Scan. It is not a cache. It is not an index. It is predicate pushdown into the storage layer itself, and it reduces data movement and database-server processing at the source.
Alongside Smart Scan, Exadata storage cells maintain Storage Indexes, which are in-memory data structures that track the minimum and maximum values of columns in each storage region. If a query asks for a range of values that does not overlap with a region, the storage server skips that region entirely. No I/O at all. This is automatic, transparent, and maintained by the storage software with no DBA intervention.
What does this mean for the bank that left Exadata? The AWS migration blog is candid about it. After the move, the team had to retune the workload. Parallel query hints that had been set to automatic on Exadata had to be pinned to fixed values. The temp tablespace had to be moved onto NVMe-backed instance storage because high temp usage was affecting reporting queries. Resource Manager consumer groups had to be created to keep batch work from interfering with interactive queries. But the main point is that Exadata’s advantage comes from running database-aware software in strategic infrastructure stack levels. Not just better hardware. Even faster conventional storage would not recreate Smart Scan or Storage Indexes; queries that benefit from those features can need a different tuning approach on RDS.
None of this is a criticism of the AWS team. It is the expected consequence of moving from a purpose-built database storage architecture to a general-purpose cloud storage architecture. The work they did with the migration was good work.
The compression story is similar. Exadata Hybrid Columnar Compression, HCC, combines columnar organization and compression algorithms in a format optimized for Exadata storage processing. Oracle has reported ratios of up to 50 to 1 on the right data, and it is transparent to the application. RDS does not offer HCC. The migration blog warns that the bank’s HCC-compressed data could expand by a factor of 3 to 5 when recompressed with Oracle Advanced Compression. The impact can survive the transfer: more storage for affected segments, more blocks for comparable full scans, and different backup capacity and duration requirements. The monthly storage bill can be higher if that extra capacity has to be provisioned. Those consequences belong in the business case.
And there is one more thing. The RDS file system is ext4, which caps a single file at 16 TiB. A bigfile tablespace in Oracle is one datafile, so the effective maximum size of a bigfile tablespace on RDS for Oracle is 16 TiB. Bigfile is the default tablespace type in RDS for Oracle, and also in new Oracle 26ai databases created with DBCA templates. Smallfile tablespaces can exceed 16 TiB by using multiple datafiles, though AWS does not recommend them as the normal choice for RDS. Several of the bank’s bigfile tablespaces exceeded the RDS limit on Exadata, so it had to reorganize the tablespace layout along business-domain boundaries before the move. That was presented as a useful cleanup, and it may have been. But the constraint will reappear if a bigfile tablespace needs to grow beyond 16 TiB. It is an RDS file-size restriction, not a limit inherent in Oracle bigfile tablespaces.
The storage architecture is where the migration’s deferred cost can live. The cutover weekend can go fine. The real friction can arrive later, when a reporting query regresses, or when the storage bill for expanded data comes due, or when a bigfile tablespace hits the 16 TiB wall and needs a different layout. None of that necessarily means the migration failed. These are consequences of the destination platform’s capabilities, and they should be in the business case before the decision is made.
The scalability ceiling, in plain numbers
The third dimension is the one that is easiest to quantify and hardest to argue with. It is the scalability ceiling.
Amazon RDS for Oracle runs on EC2 infrastructure, with both virtual machine and bare metal instance classes. As of October 2026, supported classes reach 384 vCPUs: db.r8i.96xlarge provides that count with 3 TiB of memory. The db.x2iedn.32xlarge class still offers 128 vCPUs and 4 TiB of memory. For a single writable database, you cannot add a second active RAC instance. You scale the primary vertically until you hit the largest supported class. Read replicas can scale eligible read-only workloads, but they do not provide RAC-style scale-out for writes to the same database. If your primary workload needs more compute than the largest instance provides, another architecture is needed.
Exadata, by contrast, scales in both directions. Vertically, an Exadata X11M cloud database server has 190 usable physical cores, and an elastic system starts with two servers in a RAC cluster for a total of 380 usable cores. Horizontally, Oracle Database@AWS dedicated infrastructure can expand to 32 database servers and 64 storage servers, with up to 6,080 usable database-server cores. You can add more database servers to the RAC cluster, and more storage servers to increase the I/O capacity and the storage footprint independently. Three X11M storage servers provide 240 TiB of usable disk capacity with triple mirroring, with a quoted maximum database size of 192 TiB when backups are stored elsewhere. At 64 storage servers, that maximum reaches 4 PiB, or 4,096 TiB, without compression and with triple mirroring. RDS for Oracle now reaches 256 TiB per instance through a primary volume and up to three additional volumes.
And then there is the I/O. RDS io2 Block Express can provide up to 256,000 provisioned IOPS per eligible volume; additional volumes can increase the provisioned total, subject to the instance’s I/O limits. A single ExaDB-D X11M storage server delivers up to 1 million flash write IOPS, and the three-storage-server configuration delivers up to 3 million in aggregate. These are 8K physical I/Os measured at the storage servers after ASM mirroring, not a directly comparable application benchmark against RDS provisioned IOPS. Exadata Database Service on Dedicated Infrastructure also provides triple mirroring: three copies of the data. And it comes with no separate provisioned IOPS charges, a cost that can account for a significant fraction of an IOPS-heavy RDS monthly bill.
The pricing angle is worth stating plainly because the list prices are public. Using prices checked on October 27, 2026, with 730 hours per month, USD pricing, BYOL licensing and no discounts, an RDS for Oracle db.x2iedn.32xlarge with 128 vCPUs, 64 TiB of io2 Block Express storage and 256K provisioned IOPS in Northern Virginia comes to approximately $78,200 per month in Single-AZ, or $156,400 in Multi-AZ. An Exadata X11M configuration with two database servers running RAC, three storage servers and BYOL licensing comes to approximately $36,300 per month, with 256 ECPUs provisioned in total, scalable up to the two database servers’ combined capacity of 1,520 ECPUs at additional compute cost. Oracle Database@AWS uses the same pricing as Exadata Database Service on OCI. And these Oracle infrastructure and ECPU list rates are the same across regions. For these specified configurations, Exadata costs less than half as much as RDS Single-AZ and less than a quarter as much as RDS Multi-AZ, while retaining RAC and the Exadata storage architecture. These estimates cover the specified infrastructure and database cloud services, excluding the Oracle licences and support supplied under BYOL, taxes and ancillary charges..
Oh, and ExaDB-D provides both physical database and storage servers dedicated to the customer. RDS for Oracle bare metal provides a dedicated physical compute server, while persistent storage uses Amazon EBS volumes, with no guarantee of physical disks or storage servers dedicated exclusively to that customer.
The path that is not a trade-off
The conversation so far has been about what you lose when you move from Exadata to RDS. But there is a third position, and it is the one that changes the equation entirely. You do not have to leave Exadata to get the managed benefit. Oracle now runs Exadata itself inside AWS, as Oracle Database@AWS.
Oracle Database@AWS is not RDS with Oracle branding. It is a physically separate service, jointly operated by Oracle and AWS, that deploys Exadata infrastructure inside AWS data centers. With Exadata Database Service, the databases run on Exadata. They use Exadata storage servers. They support RAC. They support HCC. They support Smart Scan, Storage Indexes, Active Data Guard, Flashback Database, Database Vault, and Real Application Testing. Oracle-certified MAA Silver and Gold architectures are available for the dedicated service. Place the application on AWS compute in the same AZ as the database, and the connection between them can use the low-latency local network..
The available formats cover different deployment sizes and operating models. Oracle Exadata Database Service on Dedicated Infrastructure, ExaDB-D, provides dedicated Exadata infrastructure with flexible server configurations for demanding consolidated estates. Oracle Exadata Database Service on Exascale Infrastructure, ExaDB-XS, is the shared, pay-per-use Exadata service that starts small and scales as you go, with Oracle-managed infrastructure. Oracle Autonomous Database on Dedicated Infrastructure runs on Exadata as well, automating tuning, patching, security updates, and scaling. Autonomous Database Serverless is another available option. All four run on Exadata. All four are available through Oracle Database@AWS. You can choose dedicated resources, shared infrastructure, or autonomous operations while keeping Exadata as the foundation.
This is what makes the “leave or stay” framing incomplete. Leaving Exadata for RDS is one path. Moving from on-premises Exadata to Exadata Database Service on Dedicated Infrastructure inside AWS is another path. Both paths get you out of the data center. Both give you managed infrastructure. Both let your application run on AWS compute and use AWS services. But one path keeps RAC and Exadata’s intelligent storage and scalability architecture available to the workload, and the other path replaces them with a general-purpose cloud database platform.
The migration itself can be simpler on the Exadata path as well. A move from an on-premises Exadata to ExaDB-D inside AWS keeps the database on the same platform. Both this route and RDS still run Oracle Database; the advantage here is keeping the Exadata features. There is no schema conversion risks inherent in that move. There is no need to abandon HCC or replace Smart Scan with a different storage model. The data moves, the logical schema can stay the same, and the target retains Exadata’s I/O capabilities. It is a move, not a transformation.
Wrapping up
When a large bank moves 119 terabytes of data from one platform to another, the headline number captures the imagination. But the real decision for any organization considering the same move is not about migration speed. It is about what the destination platform can do, what it cannot do, and whether there is a better version of the same destination.
Amazon RDS for Oracle is a managed database service that frees a team from infrastructure maintenance, and for some workloads that may be enough. But it runs Oracle Database on general-purpose cloud infrastructure, without RAC, without Exadata’s intelligent storage architecture, without Hybrid Columnar Compression, and with current ceilings of 384 vCPUs and 256 TiB of storage per instance. Moving a workload from Exadata to RDS means replacing RAC’s local active-active recovery with standby failover. It can also mean a larger storage footprint for data that used HCC and retuning for a more ordinary I/O model. You are accepting a different scaling model and different limits.
Oracle Database@AWS is the alternative that keeps the platform and changes the operating model. It runs Exadata inside AWS data centers, managed jointly by Oracle and AWS, with RAC, Smart Scan, HCC, and the scalable Exadata storage architecture. It is available in dedicated, shared, and autonomous formats, all Exadata-based. And a migration from on-premises Exadata to ExaDB-D inside AWS is a move between Exadata environments, retaining the storage capabilities that would have to be replaced in RDS.
The lesson of the U.S. Bank migration is not that leaving Exadata is fast. It is that leaving Exadata is a choice with consequences, and that the alternative of moving Exadata into AWS now exists with its RAC and intelligent storage architecture intact. For an organization that values the availability, the performance, and the scalability of the platform it already runs, the right migration is not the one that leaves the platform behind. It is the one that brings the platform into the cloud it wants to use.
