The biggest AI infrastructure decision many enterprises make in the next year won’t be a GPU investment; it will be a database upgrade. Oracle AI Database 26ai is the long-term support release Oracle is steering its 19c installed base toward. 26ai puts vector search in the same engine that holds transactions. When the vector index lives in the database, the block array and the SAN fabric behind it become AI infrastructure, carrying retrieval traffic alongside the transactions they already serve.
The Database Changed Underneath AI
Oracle built 26ai around that idea: a native VECTOR data type, SQL vector search functions, in-database model execution through ONNX, and SELECT AI for natural language queries, all in an LTS release the company enumerates at more than 300 new features. In practice, a DBA can generate embeddings, store them next to the rows they describe, and run a similarity search within the same transaction scope as an order lookup. There’s no separate vector store to run, no synchronization pipeline to maintain, and no second copy of regulated data living outside the audit trail.
IBM cites IDC on the trend: “Integrated vector databases are the clear platform of choice for storing and querying vector embeddings, as organizations favor unified, governed environments for agentic AI.” IBM and Broadcom’s customers want to extend the database they already trust before standing up a new one alongside it.
Oracle is not alone in this direction. DB-Engines’ October 2026 popularity ranking lists the top four relational and multi-model engines: Oracle, MySQL, Microsoft SQL Server, and PostgreSQL, and all four have added vector types or vector search, natively or through extensions such as pgvector. IBM chose to start its validation work with Oracle primarily because of its market leadership, though the storage argument in this piece applies to the others as well.
The arguments for keeping block storage on-prem haven’t changed with AI in the picture: the data that makes an AI deployment useful, such as patient records, claims, orders, and trades, can’t leave. Copying it to a dedicated AI platform means paying for storage twice, accepting that the copy drifts from the production cluster, and losing the governance controls that made the original legally defensible. Keeping retrieval inside the database avoids all three. The array that serves a sub-millisecond row lookup now also serves a vector similarity scan for a clinician and a backup stream at the same time.
IBM Storage and Broadcom’s Fibre Channel (FC) group set out to validate that mixed-workload case, and built an environment around Oracle AI Database 26ai on IBM FlashSystem with Broadcom’s Brocade Gen 8 SAN fabric and Emulex 64G SecureHBAs. They then worked through the questions an infrastructure team had been asking: what is the impact on transactional latency when a vector workload starts next to it, the effect of fabric speed on vector search throughput, the capacity consumed by embeddings, the effectiveness of ransomware detection when targeting an RMAN backup volume, and what are the requirements for adding a host to the SAN without a zoning ticket?
The Data Already Lives on Block Storage, and Now the AI Comes to It
None of this says AI workloads in general belong on block storage. Enterprises will keep file and object arrays for the unstructured estate: documents, images, video, training sets, and model checkpoints that never lived in a database and likely never will. In the healthcare demonstration that follows, IBM keeps the raw X-ray images in object storage while storing only the embeddings and case metadata in Oracle. What changes is the burden on the array, which now carries several workloads with very different I/O profiles at the same time.
The relational tier is the most familiar one: millions of random 4KB to 16KB I/Os per second, row lookups and commits that need to land in microseconds, heavy write concurrency from redo, undo, and checkpoint traffic, and a tail latency that stays predictable because a user-facing application is waiting on it. RMAN, Oracle’s backup utility, is the opposite: a sequential stream that needs headroom to finish inside its window without disturbing the first workload. Both are well understood, and IBM’s arrays are tuned for them.
The vector tier is harder to characterize because large tables of vector embeddings can make vector search look like a bandwidth-intensive workload: a large sequential scan. IBM’s characterization of the Oracle 26ai vector path is closer to OLTP. Each hop through the index is a roughly 4KB random read; the query path is IOPS-bound and latency-sensitive, and reads dominate because writes live in a separate ingest and index-build phase.
Bandwidth matters in bursts, when an index is built or a corpus is re-embedded, and those bursts tend to be quite large. That split is the core of the mixed-I/O problem: on the query path, the vector workload competes with transactions for the same queues, making isolation a quality-of-service concern. And the bursty phases are where fabric bandwidth becomes the ceiling, as the 32G versus 64G results later in this piece show.
The Validated Architecture
IBM and Broadcom built one environment for this validation in Broadcom’s Colorado AI lab. The storage is an IBM FlashSystem 9000 series array running IBM Storage Virtualize 9.1.3 with 24 FlashCore Modules, presenting 64G Fibre Channel ports to a pair of Brocade Gen 8 G820 SAN switches. The database host is a dual-socket Intel Xeon 6767P server with two 2-port Emulex LPe38102 64G SecureHBAs, running Oracle AI Database 26ai on ASM with no GPU in the storage path; IBM Storage Insights watches the array.
We ran the fabric and capacity results, the 32G versus 64G vector search comparison, and the footprint measurements using VectorDBBench against the BioASQ 1M dataset on that host alone. The same configuration also supports the application workload. A Supermicro 821GE-TNHR with two Xeon Platinum 8470 processors and eight NVIDIA H100 80GB GPUs hosts the healthcare application and its language model. The software stack includes Oracle’s in-database ONNX embedding, Ollama serving Llama 3, and NVIDIA cuVS. A Broadcom Tomahawk 5 switch and Thor 2 400GbE NICs connect the two servers. The I/O QoS, multi-tenancy, ransomware detection, and healthcare demonstrations ran in this environment.
According to IBM, the FlashSystem family (the 5300 and 5600, 7300 and 7600, and 9500 and 9600) runs the same Storage Virtualize software, and the functions demonstrated here, including I/O throttling, AutoZoning, ransomware detection, Policy-Based HA, and storage partition migration, work the same way with Oracle AI Database 26ai on any of those arrays at the same code level. Performance and density vary by model and FlashCore Module generation, so every figure in this piece belongs to the system it was measured on.
Ensuring Optimum OLTP and Vector Workload Performance With I/O QoS
The first question IBM and Broadcom set out to answer is the one every DBA asks when a vector workload is proposed for the production array: what happens to the core transactions? IBM ran it as two demonstrations on the FlashSystem 9000 series array using volume-level I/O throttles, the mechanism behind what IBM calls I/O QoS. The database was laid out across 30 volumes: 15 for the OLTP tablespaces (ORCL16 through ORCL30) under Swingbench Order Entry at 192 users, and 15 for the vector tables (ORCL31 through ORCL45) under a 200-thread synthetic generator running top-k 500 similarity queries, with Storage Insights charting each volume group.
With OLTP running alone, each OLTP volume held a flat 20,500 ops/s. When the vector generator started, the vector volumes climbed to about 73,000 ops/s each within a minute, and the OLTP volumes fell to about 13,000, a 37 percent drop with nothing changed on the transactional side. The vector search path is 4KB random reads at the same block size as the transactions, so it hits the same queues and takes whatever the array will give it.
A 45,000 IOPS cap on each vector volume, one line of mkthrottle at the CLI, pulled the vector volumes to the limit and lifted OLTP back to about 17,000 ops/s. Removing the cap reversed it, and when the vector run ended, OLTP returned to 20,500. The dashboard tracked the same thing in aggregate: 1.28 million IOPS unthrottled and roughly 950,000 under the cap, which, within a few percent, is the per-volume rate times 30 volumes.
The second demo is the configuration IBM expects would deploy in production: caps set first, 45,000 IOPS per vector volume and 20,000 per OLTP volume, then both workloads launched together. The vector volumes ran at their ceiling, the OLTP volumes settled at about 12,200 ops/s and stayed flat for the length of the run, and the array held 870,000 IOPS (800,000 read, 70,000 write) at 377 microseconds and 6.9GB/s on 25% CPU. The OLTP cap sat above the workload’s demand and never engaged; it’s there so a runaway on either side can’t starve the other.
Swingbench held its 192 users at about 1.19 million transactions per minute, roughly 19,500 TPS, for the length of the run. The generator was tuned to saturate its volumes, so its per-query latency isn’t an application benchmark. Over the 30-minute run, it completed 35,672 queries at 19.8 per second, with a median latency of about 10 seconds and a p99 of 14.3 seconds against a 15-second application timeout; 99 queries (0.28 percent) hit that timeout, and the transactions never noticed any of it.
A FlashSystem throttle is a volume ceiling enforced at the array regardless of host or path, with an optional bandwidth limit alongside the IOPS limit; it caps the neighbor and reserves nothing. The cap is a sizing exercise: 15 vector volumes at 45,000 IOPS is 675,000 IOPS of vector headroom, which left this array’s OLTP volumes what they needed. A different array or mix moves the number around some. Set the vector cap where the transactions hold their latency, and the vector workload gets everything above it.
Ransomware Detection on Live Oracle Volumes
Sophos’s 2024 survey of 2,974 organizations hit by ransomware found that 94 percent saw the attackers go after their backups, that the attempt succeeded 57 percent of the time, and that median recovery costs ran eight times higher when it did. IBM built the test on the same premise, backups first and production second, and aimed the attack at the RMAN backup target while leaving the database volumes alone. RMAN wrote its backup sets to FlashSystem volumes, a ransomware simulator was run against them, and the array was left to notice on its own, with no host agent in the path.
Detection happens inside the drives: FCM4 and FCM5 FlashCore Modules compute entropy and compressibility on every write as it lands, along with block size, address, and rewrite patterns, and every two seconds pass a per-volume summary to an inference engine inside Storage Virtualize (8.6.3 or later with FCM firmware 4.1 or later). The model raises alerts in the FlashSystem GUI and IBM Storage Insights Pro, forwards them to Storage Defender or a SIEM, and is patchable on its own, so a retrained model ships as a small security update with no firmware upgrade.
Because the analysis runs on the module, it keeps working even when the host is what’s compromised. Encrypted output is high-entropy and stops compressing, and that shows up in the statistics whether the attacker changes file extensions, encrypts only every other block, or slows the rate to hide from an endpoint agent.
During validation, RMAN wrote the backup over 16 parallel channels, with each backup set capped at 150GB, and the database sat on 15 x 200GB disks per ASM disk group for OLTP and vector data. IBM ran the attack against that backup target, and the alert reached Storage Insights in under 60 seconds, which is within the detection window IBM publishes for the feature. Storage Insights flagged all 31 volumes in the volume group, since an alert on one volume marks the whole group as a threat.
The response is Safeguarded Copy, and the array handled it without an operator: the FlashSystem took an immutable snapshot of the affected volume group the moment the threat was raised and extended the retention of the last-known good snapshot at the same time. The lsanomalydetection output from the array shows the configuration behind that: inference engine 8.0 with model 0.3.42.0, anomaly_snapshot on, 30 days of retention on the new snapshot, and 30 days added to the last good one. Storage Virtualize also marks the suspect snapshot so nobody restores from it, leaving a clean restore point from before the encryption began.
The fabric also carries a security layer. Broadcom builds post-quantum cryptography into Brocade Gen 8, the Emulex SecureHBAs encrypt data in flight between host and fabric, and FCIA’s new FC-SP-3 standard sets the quantum-ready security baseline for Fibre Channel as a whole.
SAN Growth Without Zoning Tickets: IBM FlashSystem AutoZoning Using Broadcom Target-Driven Zoning
Adding a host to a Fibre Channel SAN usually takes a ticket and two teams: the server admin collects the HBA WWPNs, the SAN admin builds zones on both fabrics by hand, and the storage admin maps the host to the right target ports. One mistyped WWPN leaves a new Oracle RAC node without its paths. AutoZoning moves that work to the array: FlashSystem talks to the fabric directly, identifies the initiator WWPNs, selects target ports, and creates the zones itself, with no one logging into a switch.
The feature is built on Brocade Target Driven Zoning (TDZ) and arrived in FlashSystem software 9.1.2. It requires Brocade switches running Fabric OS 9.1.1 or later, with TDZ enabled by the fabric administrator on the switch ports facing FlashSystem target ports. That enablement is the one step that stays with the SAN team, and AutoZoning takes no action on a port until it’s done. From there, FlashSystem builds peer zones, allowing host initiators to reach the target port but not each other, under a predictable IBM_SV_ name that marks them as array-managed.
Setup starts in the Fibre Channel port view, which now shows the switch each port connects to, whether the port is AutoZone capable, and whether its connectivity is symmetric, meaning the same port ID on every node lands on the same fabric. A topology view maps that in color, and only green ports that are active, AutoZone capable, and symmetric support AutoZoning. Asymmetric ports stay out even if otherwise capable, since the GUI warns it can compromise redundancy and failover.
Host creation starts from an Unconfigured hosts list, filled through FDMI, which reports each HBA’s host name, operating system, and ports to the fabric. In IBM’s walkthrough, the Add Host dialog opened with the server name, operating system, and both HBA ports of a host that had no zones yet already populated; the admin picked an AutoZone-enabled port set, which defines the target ports the host can reach, and clicked Add. FlashSystem paired its target ports with the host initiators, pushed the zones to both switches, and the host came online with four paths across two fabrics.
For Oracle, IBM positions AutoZoning for adding RAC nodes and replacing HBAs, since the feature tracks changes in host or storage connectivity and adapts zone definitions to match, so a swapped HBA doesn’t require a manual rezone. The same automation applies when hosts need paths to a second array for storage partition migration or Policy-Based HA (PBHA). The SAN team still controls which target ports participate, since nothing happens on a port until they enable TDZ. Consequently, adding a host no longer waits on a zoning change.
Operational Envelope: PBHA, Grid Migration, Multi-Tenancy, and Placement
Policy-Based HA (PBHA) synchronously replicates a storage partition between two FlashSystem arrays at metro distance, with active-active host access at both sites. IBM says the feature is designed for zero RPO and for a storage failover that a properly clustered Oracle deployment can ride through without data loss. When the failed site comes back, the data resyncs and the workload moves back without an outage.
The FlashSystem Grid feature federates up to 32 FlashSystem arrays under one management view, and storage partition migration moves a partition, with its volumes, volume groups, and hosts, from one array to another without application downtime. For Oracle, IBM points to hardware refresh, draining a system before a firmware update, and moving a vector partition to a system with more capacity as the embedding set grows. A system migrates one partition at a time over Fibre Channel or high-speed Ethernet; hosts can connect over Fibre Channel, iSCSI, or NVMe/TCP, and a partition already configured for PBHA is not eligible for migration.
The Storage Insights placement advisor handles planning for the same grid. Given a workload’s capacity, growth rate, I/O profile, and latency target, it scores every system in the grid, ranks the best fit before anything is provisioned, and can also recommend a migration when it spots a CPU or IOPS imbalance. Migration and placement both use Storage Insights Pro, with every grid system registered to the same Storage Insights tenant.
Multi-tenancy lets a DBA team and an AI team share that grid without sharing administration. In IBM’s walkthrough, an administrator created two tenants on the same array (Tenant_Scale and Tenant_oracle_ai) and gave each one a system, a user group with a tenant role, and a first user. They then built a storage partition for each with a separate volume group, volumes, and host mappings. The GUI offers to configure replication as soon as a new partition exists. Logged in as the Tenant_Scale user, the GUI showed only that tenant’s partition and resources, with nothing belonging to Tenant_oracle_ai, and the same check from the Tenant_oracle_ai side returned the same result.
The Fabric Dividend: 32G vs. 64G Fibre Channel Under Vector Search
The one variable IBM and Broadcom changed in this testing, on purpose, was the fabric. The same array, host, and Emulex LPe38102 SecureHBAs ran VectorDBBench against the BioASQ 1M dataset (one million 1,024-dimension vectors from the biomedical question-answering corpus) twice: once with the two HBA ports at 32G and once at 64G, through the same Brocade G820 switches. Everything else, from the 16 ASM volumes to the 4GB SGA, stayed put, so the difference between the two runs is the Fibre Channel generation and nothing else.
The search phase of this benchmark is a read-only scan: Oracle’s IVF_FLAT index routes each query to a cluster of partitions and reads them in full, and with 1,024-dimension FLOAT32 vectors, that is a bandwidth workload. On two 32G ports, host-side reads leveled at 6.3GB/s, the line rate of the pair, and the search curve flattened at 43.7 queries per second with 20 threads. On two 64G ports, the same host read at 12.5GB/s and kept scaling to 85.0 QPS at 80 threads, 95% more throughput from the same storage.
Latency tells the other part of the 64G story: at one thread the two fabrics are within 8% of each other, 0.107 seconds against 0.099, because a single query never fills either pipe. From five threads on, however, the 32G run queues: average latency doubles the 64G figure at every step, and at 80 threads p99 reaches 4.08 seconds against 1.14. A saturated FC fabric doesn’t fail; it queues every query, and that wait shows up as tail latency.
The load phase moved too; ingesting the million vectors took 94.1 seconds on 32G and 84.5 on 64G, and the IVF_FLAT index build took 139.6 seconds against 108.4, 28.8% longer on the slower fabric, for a total load of 233.7 seconds against 193.0. Recall and NDCG were within 0.1% across the two runs (83.81% and 84.42% on 32G, 83.95% and 84.56% on 64G), so the fabric changed how quickly answers arrived. For a database that has been on 32G since deployment, the HBA and switch upgrade is an obvious opportunity to deliver more performance.
Planning for Vector Capacity Growth
Vector search changes the capacity math before it changes performance. An embedding is a fixed-width numeric copy of a chunk of source data, and for text that copy is usually larger than the chunk it describes: a 1,000-byte passage becomes a 1,024-dimension FLOAT32 vector of 4,096 bytes before the database adds a row to hold it. The team calls this vector storage amplification, and measured it on the same BioASQ 1M dataset used in the fabric comparison.
The source text behind the million vectors is 0.90GB. In Oracle 26ai, it became a 7.67GB vector table, including about 0.3GB of row overhead, and the IVF_FLAT index added 8.57GB on top because it keeps a second, clustered copy of every vector plus roughly 4MB of centroids. The persistent footprint on the SAN is 16.24GB, 18 times the source text, before the operational space Oracle needs around it: 15 to 23GB of TEMP while the index builds, and 4 to 8GB of UNDO and about 15GB of REDO during ingest.
The multiplier scales with the embedding model: Broadcom extrapolates from the same method, putting a 768-dimension Cohere v3 model (also measured) at 4.8x the source, a 384-dimension MiniLM at 9.6x, and a 4,096-dimension Mistral model at 32.5x. Chunk size matters as much as width, since a wide vector over a long passage amplifies less than the same vector over a short one, and quantized indexes shrink the index share.
None of this is specific to FlashSystem or to Oracle. The amplification happens inside the database before the array sees a byte, and every vector index on every platform carries a copy of the vectors, so it belongs in the capacity budget the day a vector project is approved, alongside the GPUs. What the array decides is how much of that growth it can hold: IBM’s fifth-generation FlashCore Module runs to 105.6TB per module, which puts 3.3PB raw in a 2U enclosure on the largest FlashSystem models, 11.8PB effective by IBM’s figure, so a vector tier can grow in place for years before a partition has to move.
IBM’s sizing model for the healthcare application that follows runs the other way for images: 100GB of X-rays yields roughly 2GB inside the database, since only the embeddings and case metadata live there. Text is the expensive case: 100GB of chunked clinical text lands at 860GB to 1.2TB, most of it HNSW index. The sizing input is the chunk count and the model width; the source corpus is a poor guide. Embeddings also compress less than rows, 1.2x to 2x vs. 2x to 4x for relational data, per IBM’s experience, so FlashCore Module data reduction recovers less of the growth, and every re-embed needs the TEMP space again.
IBM’s practical rule is to measure before committing. Load 1 to 5 percent of the real corpus with the production embedding model and chunking settings, measure the actual bytes per vector, then scale linearly, and repeat the exercise whenever the model, the dimension count, or the chunking policy changes.
End-to-End AI Inferencing: The Healthcare Application
IBM built the application for this validation as a radiology and gastroenterology assistant called RAD-AI. It is a sample application with production-style requirements, and in this paper it demonstrates a complete inference pipeline on the same array and fabric the earlier sections measured. A clinician enters a patient’s age, sex, and presenting complaint, uploads a chest X-ray or endoscopy image, and receives a structured report built from the most similar prior cases in the archive.
The archive holds 112,120 chest X-rays from the NIH ChestX-ray14 dataset and more than 10,000 GI endoscopy images from HyperKvasir, including per-frame vectors from 367 full endoscopy videos, for more than 172,000 pre-embedded cases. Each image becomes a 768-dimensional vector from a CLIP ViT-L/14 model running inside Oracle AI Database 26ai through its ONNX runtime, so the embedding lands in the same transaction as the row that holds it. The raw images stay in object storage; the vectors and case metadata live in Oracle.
At query time, Oracle runs an approximate nearest-neighbor search by cosine distance across the archive and returns the closest cases, along with their original findings, diagnoses, and outcomes. That retrieved set is the context for Llama 3, served by Ollama on one of the H100 GPUs in the Supermicro server, which writes the report: a clinical priority, a findings summary, a ranked differential diagnosis, and recommended actions, with the matching cases listed beneath it. Endoscopy follows the same path and adds a clinical note; for video, the pipeline embeds frame-by-frame so it can track a lesion along the GI tract.
The application runs two workloads against the same FlashSystem volumes. The transactional workload covers logins, report storage, audit logging, and sessions; the vector workload performs high fan-out random reads across the embedding tables and case metadata, matching the generator profile in the I/O QoS demonstration. IBM’s deployment sets the volume throttles described earlier so a batch re-embedding job cannot slow a clinician entering a case, and the ransomware detection and partition migration shown above apply to these volumes unchanged.
The resource-heavy step is building the archive, which IBM measured by embedding the full 112,120-image chest X-ray set twice with the same model and the same VECTOR(768, FLOAT32) target. With the ONNX model running inside the database on the host CPUs, the pipeline sustained 3.41 images per second at 0.272 seconds per embedding, and the full set took 9.1 hours. Moving the model to Oracle’s Private AI Services container on the second server raised throughput to 8.55 images per second (0.097 seconds per image), and the same ingest finished in 3.6 hours.
Preprocessing (about 0.019 seconds per image) and the Oracle insert (under a millisecond) were identical on both runs, so the 2.5x gain comes entirely from where the model executes. The Private AI Services embedding service runs on a CPU ONNX runtime, so the H100s in that server sat out this test; the gain came from taking the model off the database host, and the GPU’s share of the pipeline is the index build covered next.
IBM measured these figures in the Colorado lab; we did not run or audit the test. The practical takeaway is that the first embedding of an archive, and every re-embed after a model change, is a batch job measured in hours, while the retrieval that follows is a CPU and storage job measured in milliseconds.
The same container also handles index construction. Oracle 26ai can send an HNSW build to the container’s Vector Index Service, which uses NVIDIA cuVS on the GPU to build the neighbor graph before returning the completed index to the database. Searches then run without GPU involvement. In IBM’s recording, the baseline HNSW build (32 neighbors, efConstruction 200) took 8.47 seconds in the database and 2.26 seconds with the offload, a 3.7x reduction. That run used a small demonstration table, so it confirms the path works on this configuration; we still need to measure the clinical-scale number.
The application demonstrates the division of labor at the heart of this paper. The GPU server hosts the language model and, during archive builds or rebuilds, the embedding and indexing services. The database stores vectors alongside the records they describe, while the array and fabric handle retrieval reads and transactions. No step in the retrieval path uses an external API, and patient data never leaves the data center.
IBM chose healthcare as the vertical to prove the concept, and nothing in the pattern is specific to it. Swap the X-ray archive for claims histories, maintenance records, or a product catalog and the same three pieces carry over: vectors stored beside the records they describe, generation on the GPU server, and retrieval and transactions on one array. Any industry running inference against data it already holds lands on the same architecture.
What Comes Next
The validation continues on the same hardware: Phase 2 moves the inference engine’s KV cache from GPU memory onto FlashSystem over the same Fibre Channel fabric, so a long-context model keeps more of its working set in reach; the next paper in this series covers that work. IBM is also building a content-aware refresh pipeline, with IBM Storage Scale AFM and Kafka feeding new documents into in-database ONNX vectorization as they arrive, so the vector index tracks its sources without a batch re-embed. IBM also plans to extend the same storage validation to the other multi-model databases that have added vector search.
Phase 2 also puts the security layer to work on new data. When the KV cache moves onto FlashSystem, a healthcare model’s working context (patient history included) crosses the same Fibre Channel links as the vector index and the transactional records. Emulex SecureHBAs encrypt it in flight between host and fabric while Brocade Gen 8’s post-quantum cryptography covers the switch side. Each phase adds a workload to the fabric without adding a path where data travels in the clear.
Leaderboard: IBM’s profile on our Best Storage Arrays page now covers FlashSystem block storage alongside Storage Scale.
This report is sponsored by Broadcom. All views and opinions expressed in this report are based on our unbiased view of the product(s) under consideration.
Amazon