diff --git a/drivers/nvme-queue.hh b/drivers/nvme-queue.hh
index d7e318617..0d2b680ba 100644
--- a/drivers/nvme-queue.hh
+++ b/drivers/nvme-queue.hh
@@ -122,7 +122,11 @@ protected:
     static constexpr size_t max_pending_levels = 4;
 
     // Let us hold to allocated PRP pages but also limit to up 16 ones
-    ring_spsc<u64*, unsigned, 16> _free_prp_lists;
+    // Cache of pre-allocated PRP-list pages for multi-page I/Os.  Sized to the
+    // IO queue depth class so a deep, busy queue rarely misses into alloc_page()
+    // on the submit path; a miss still falls back to alloc and a full pool frees
+    // on return, so this is a churn optimization, not a correctness limit.
+    ring_spsc<u64*, unsigned, 128> _free_prp_lists;
 
     mutex _lock;
 };
diff --git a/drivers/nvme.hh b/drivers/nvme.hh
index b1449f3bf..73b64672c 100644
--- a/drivers/nvme.hh
+++ b/drivers/nvme.hh
@@ -29,7 +29,14 @@
 #define NVME_ADMIN_QUEUE_SIZE 8
 
 //Will be lower if the device doesnt support the specified queue size
-#define NVME_IO_QUEUE_SIZE 64
+// A deeper IO queue lets many I/Os stay in flight concurrently instead of
+// blocking submitters on a full submission queue.  Under a concurrent database
+// workload on real (native NVMe) hardware the old depth of 64 filled quickly,
+// serializing threads on the sq-full wait; 256 keeps more requests in flight
+// without materially more memory.  The device's advertised max (cap.mqes) still
+// clamps this in create_io_queues(), so it is safe on controllers with a
+// smaller queue-entry limit.
+#define NVME_IO_QUEUE_SIZE 256
 
 namespace nvme {