Update FAQ.md

Author: abonander

FAQ.md

@@ -36,6 +36,62 @@ as they can often be a whole year or more out-of-date.
 
 [`rust-version`]: https://doc.rust-lang.org/stable/cargo/reference/manifest.html#the-rust-version-field
 
+----------------------------------------------------------------
+
+### Can SQLx Add Support for New Databases?
+
+We are always open to discuss adding support for new databases, but as of writing, have no plans to in the short term.
+
+Implementing support for a new database in SQLx is a _huge_ lift. Expecting this work to be done for free is highly unrealistic.  
+In all likelihood, the implementation would need to be written from scratch.  
+Even if Rust bindings exist, they may not support `async`.  
+Even if they support `async`, they may only support either Tokio or `async-std`, and not both.  
+Even if they support Tokio and `async-std`, the API may not be flexible enough or provide sufficient information (e.g. for implementing the macros).
+
+If we have to write the implementation from scratch, is the protocol publicly documented, and stable?
+
+Even if everything is supported on the client side, how will we run tests against the database? Is it open-source, or proprietary? Will it require a paid license?
+
+For example, Oracle Database's protocol is proprietary and only supported through their own libraries, which do not support Rust, and only have blocking APIs (see: [Oracle Call Interface for C](https://docs.oracle.com/en/database/oracle/oracle-database/23/lnoci/index.html)).
+This makes it a poor candidate for an async-native crate like SQLx--though we support SQLite, which also only has a blocking API, that's the exception and not the rule. Wrapping blocking APIs is not very scalable.
+
+We still have plans to bring back the MSSQL driver, but this is not feasible as of writing with the current maintenance workload. Should this change, an announcement will be made on Github as well as our [Discord server](https://discord.gg/uuruzJ7).
+
+### What If I'm Willing to Contribute the Implementation?
+
+Being willing to contribute an implementation for a new database is one thing, but there's also the ongoing maintenance burden to consider.
+
+Are you willing to provide support long-term?  
+Will there be enough users that we can rely on outside contributions?  
+Or is support going to fall to the current maintainer(s)?
+
+This is the kind of thing that will need to be supported in SQLx _long_ after the initial implementation, or else later need to be removed.
+If you don't have plans for how to support a new driver long-term, then it doesn't belong as part of SQLx itself.
+
+However, drivers don't necessarily need to live _in_ SQLx anymore. Since 0.7.0, drivers don't need to be compiled-in to be functional.
+Support for third-party drivers in `sqlx-cli` and the `query!()` macros is pending, as well as documenting the process of writing a driver, but contributions are welcome in this regard.
+
+For example, see [sqlx-exasol](https://crates.io/crates/sqlx-exasol).
+
+----------------------------------------------------------------
+### Can SQLx Add Support for New Data-Type Crates (e.g. Jiff in addition to `chrono` and `time`)?
+
+This has a lot of the same considerations as adding support for new databases (see above), but with one big additional problem: Semantic Versioning.
+
+When we add trait implementations for types from an external crate, that crate then becomes part of our public API. We become beholden to its release cycle.
+
+If the crate's API is still evolving, meaning they are making breaking changes frequently, and thus releasing new major versions frequently, that then becomes a burden on us to upgrade and release a new major version as well so everyone _else_ can upgrade.
+
+We don't have the maintainer bandwidth to support multiple major versions simultaneously (we have no Long-Term Support policy), so this means that users who want to keep up-to-date are forced to make frequent manual upgrades as well.
+
+Thus, it is best that we stick to only supporting crates which have a stable API, and which are not making new major releases frequently.
+
+Conversely, adding support for SQLx _in_ these crates may not be desirable either, since SQLx is a large dependency and a higher-level crate. In this case, the SemVer problem gets pushed onto the other crate.
+
+There isn't a satisfying answer to this problem, but one option is to have an intermediate wrapper crate.
+For example, [`jiff-sqlx`](https://crates.io/crates/jiff-sqlx), which is maintained by the author of Jiff.
+API changes to SQLx are pending to make this pattern easier to use.
+
 ----------------------------------------------------------------
 ### I'm getting `HandshakeFailure` or `CorruptMessage` when trying to connect to a server over TLS using RusTLS. What gives?