1、 我曾经使用过Diesel、SQLx和Cornucopia https://github.com/LouisGariepy/cornucopia。
当SQLx出现的时候，我立即抛弃了Diesel，仅仅使用SQL作为与数据库对话的语言对我来说是最有意义的。
SQLx增加了你的增量构建时间。
我现在使用Cornucopia，它有和SQLx一样的检查，但对构建时间的影响要小得多。
2、Diesel 目前（至少在标准设置下）不支持异步。除此之外，它很棒，但这对我来说太大了。
我也尝试过tokio postgres，但它缺少连接池。
在我看来，目前最好的选择，也是我目前在生产中使用的，是sqlx。
3、sea-orm 很棒并且建立在 sqlx 之上
我已经使用sqlx、sea和diesel有一段时间了。
我可以说，尽管sea真的很好，但它还没有成熟到可以在PROD中使用（我已经在他们的GH上报告了几个问题），但如果你不想做任何严重的事情，它是比较好的。
Diesel的主要问题是JOIN操作，几乎不可能只用Diesel来做这些操作。
我所尝试和使用的最令人愉快和准备就绪的PROD是SQLx，从我的经验来看，使用它的缺点很少。主要是要自己写SQL查询，但另一方面，在我看来，它也更具有可读性和优化性。另一个缺点是，如果你决定迁移你的数据库引擎，你需要重新写所有的查询。
4、SQLx乍看之下似乎是一个非常好的解决方案。但至少从我的观点和我看一些例子的经验来看，有以下几个问题。
- 性能。SQLx + sqlite的性能始终比Diesel或Rusqlite慢（而且不是小幅度的）。这也适用于任何建立在SQLx之上的东西，比如sea-orm。问题似乎是他们的异步优先的方法与sqlite的工作方式不一致。
- "动态查询"。SQLx的编译时查询检查宏要求在编译时就知道整个查询。这意味着一旦你包含一些动态部分，就不可能再检查这些查询。(这里的动态是指简单的结构，如基于可变大小的容器的IN (?, ?, ?) 列表，因为这些需要可变数量的绑定调用，这导致了动态查询。) Sea-orm通过拥有一个查询生成器来 "解决 "这个问题，但这并没有提供与SQLx或Diesel相同的保证水平。
- "类型检查方法的局限性"。乍一看，似乎SQLx应该能够静态地检查复杂的查询。在实践中，有些查询他们会推断出错误的列类型。例如，这发生在NOT NULL约束和LEFT JOIN。他们为这个问题提供了解决方法，但这需要手动为查询注释额外的类型信息。(同样，这并不适用于sea-orm，因为他们提供了一个动态查询生成器，在编译时执行有限的类型检查）。
所有写好的Diesel本身显然也不是银弹解决方案。如果出了问题，Diesel往往会在编译时产生大量的错误信息，以表明某些查询是无效的。虽然这能抓住根本问题，但这些错误信息需要一些实践来了解那里发生了什么。此外，Diesel试图在编译时通过类型系统进行检查。这可能会限制真正的动态结构（例如，你指定一个动态的列列表作为选择子句）。