How to write code that works across the four supported engines?

[mcclure]

This is sort of half a support request, and half a request your documentation add some clarifications.

Context: I want my Rust app to store data in a database. I would mostly prefer a relational database. I would find SQL slightly more convenient than an ORM. If I'm going to do SQL, I would like to support all four of SQLite, MariaDB, MySQL and Postgres. I intend to run the app with SQLite, but I want to support MariaDB and Postgress in case other people use my app, or in case SQLite turns out to have performance issues and I have to run on my creaky old MySQL server. A friend suggests SQLx. I look it up and see SQLx brag at the top that it is "Database Agnostic." Great! This looks like what I want.

But when I start cracking into the docs, I find: "SQLx is not an ORM!". This explains that during compilation "connects to your development DB" and this is how the checked SQL feature works. Uh oh! This says to me that if I develop code against SQLx with my SQLite development database, I could potentially accidentally write SQL which mismatches the dialect of those other. In other words, sqlx itself is database agnostic, but code targeting sqlx is not database agnostic, which is not quite what I expect when a library describes itself as "database agnostic". The FAQ explains that having SQLx do the checking internally is infeasible because you'd have to support every dialect of every server, which is fair, but I do not want to support every dialect, I want to support the 4 (3.5?) mainline open-source databases that SQLx supports currently. (I don't see a reason to support proprietary RDBMS.)

With this context, here are my Questions:

1. Given sqlx checks sql syntax by calling out to database engines, is there a way to configure sqlx to call out to multiple database engines? For example, although I do not want to do this, I could install mariadb and postgres on my development machine; sqlx could then in principle, when it does its sql checks, call out to all three and give me an error if any of the three complain.

2. Is there some way the sqlx docs/FAQ could, or should, be changed to prevent confusion about the meaning of "database agnostic" (e.g.: sqlx supports any database engine, but that does not mean your sqlx code is "write once run anywhere" for database engines). I imagine someone with limited SQL experience sincerely believing that by using SQLx they are writing code that supports the four SQLx-supported engines. ("SQLx is not an ORM" does not adequately express this idea imo; an ORM is not the same thing as a database abstraction layer, even if ORMs are the most common form of database abstraction layer.) A single sentence in the "SQLx is not an ORM" page would do a lot to clarify.

3. Given what I've described above, is SQLx the correct choice for me, and/or should I consider using an addon such as one of the ORMs¹ described on the "ecosystem" page? (The reason I'm resisting ORMs is that I know SQL, but every ORM is a new unique-snowflake system I'd have to learn, and because the ecosystem page links three (3) ORMs I'm looking at the possibility of learning up to three separate ORMs before I know for a fact which ORM fits my use case and can start writing actual code.)

---

TL;DR Is there a way to write database-agnostic SQLx code, and how can I (at least to first order) verify this is what I am doing?