在SpringOne平台华盛顿大会上宣布的R2DBC是一个从头开始设计的实验性API，用于针对关系型数据库进行反应式编程。最终目标是试图影响ADBA规范。
在活动中，Cloud Foundry Java Experience团队负责人Ben Hale表示，R2DBC的设计原则是基于以下四个原则：
- 利用反应式流类型和模式；
- 访问数据库的整个过程完全非阻塞；
- 把驱动SPI压缩为专门实现的最小操作集，且不管可用性；
- 基于驱动SPI实现多个“人性化”的API。
这是Hale幻灯片中的一个例子，一个简单的Select语句：
connectionFactory.create()返回一个Mono连接。Hale解释说，这个调用的结果是，“最后，当有人订阅，它会获取一个连接，执行查询，然后为每一行返回值，比如说一个整数，最终生成一个整数Flux作为结果，连接的生命周期是在订阅时打开、完成后关闭。”
当然，构建在SPI之上的客户端可以对其进行进一步地简化，Hale给出了这样一个隐藏细节的例子：
下面是使用SPI时一个事务中的Prepared Insert的例子：
正如Hale在演讲中承认的那样，这并不是很好，但同样可以在客户端简化：
有一些替代R2DBC的方法。一种方法是将JDBC封装在线程池中，但这不会提供回压——无界队列将导致资源耗尽，而有界队列将导致阻塞。另一个是ADBA。Hale谨慎地说：
我们很早就与ADBA的工作人员进行了接触，但是，关于CompletableFuture是否真的是Reactive有很多不同的看法，所以我们放弃了，这促成了R2DBC的工作。但现在，R2DBC已经有了经过实际证明的、可以使用的API，我们再次被邀请参与进来。因此，ADBA可能会变成这样，在某种程度上，这是像这样一个项目的最终目标。
至于未来计划，Hale明确表示，R2DBC是一个实验场，虽然它足够稳定可以使用，但绝对不能用于生产环境。需要注意的是，有很多边缘情况，包括缺少BLOB/CLOB处理，并且目前只支持写入一个数据库——PostgreSQL，但是Hale希望看到面向其他数据库的实现。他最后说：
Spring不会生成规范。我们不是规范引导者，也不管理规范。这个项目的全部目标是为了影响ADBA规范，这是最好的情况。但毫无疑问，我不是那种会容忍ADBA规范不好的人。如果他们不接受我们的建议，如果他们没有看到Reactive与async的区别，那么，这就是Spring团队将要做的事情。