问这个问题表示你没有真正理解整体设计
vert.x能不能用orm？当然可以，这两个一点都不冲突，pure orm是纯内存的操作，本身可以被认为是非阻塞式的操作，所以直接套上去就可以了，但是：
1)vert.x没有提供傻瓜化的框架和api，不像hibernate那些那样，同时网络上也有很多教程，vert.x不是这样的，这些东西你要自己完成，实际上也不困难，无非resultset和object互相转换，自己用反射之类的动手写也就那么一回事
2)为什么vert.x没有提供傻瓜化的框架呢？因为用vert.x的人，本身对于rdbms有些说白了，就是瞧不上，因为数据库会先于应用服务器触发吞吐瓶颈，一个传统系统，比如是tomcat和mysql的组合，当并发量上去之后，mysql会先于tomcat之前顶不住，所以第一步一般是引入nosql以增加吞吐，比如cassandra，同时会弱化mysql等的rdbms的属性，以提速增加吞吐，比如用pg替换掉mysql，用jsonb类型替换掉传统的table表，然后才是把tomcat等换成vert.x，等到你用vert.x的时候，vert.x面对的是一个json等的数据结构，以及nosql的数据库，所以vert.x优先解决跟nosql以及json等半结构或者无结构数据格式的交互问题，提供能够跟json，文件系统的api，而不是去适应传统的rdbms，那个是落后产能
这有一个逻辑推断，就是如果你还在用rdbms，意味着数据持久化本身成为瓶颈，用不用vert.x都改变不了这个瓶颈的存在，比如tomcat吞吐是2000，但是rdbms是1000，你换成vert.x，把appserver的吞吐提高到40*2000=80000，但是rdbms怎样都只能吞吐1000，你的系统最终的吞吐也还是只有1000，vert.x跑得再快又怎样？所以用vert.x是跟整个系统发展趋势相符的，光换vert.x可能并不能整体提升系统性能，还需要其他部分整体配合才行，否则就像开着法拉利拖了个牛车
所以vert.x的module取舍很简单，对于这些落后的产能，它干脆连api都懒得去弄，就像同步的api，你说vert.x能不能做成传统的一个request一个thread处理的形式？当然可以，但是这样做就慢，要做你自己做，提供傻瓜化api并不是发展的重心
朝前看
