It's not on the roadmap right now but we could consider it after implementing support for async java drivers.

@Tapac I really love this library and using with Ktor and Android. I am not sure how much effort it will take to make it compatible with Kotlin multiplatform but certainly, if you consider it to do sooner, it would certainly lead over SQLDelight.
Just imagine, if you are using the same library for server-side and your Android app and get support for multiplatform, how wonderful a dev life would be. :) Multiplatform already provides libraries for Coroutine, Http client, Serialization support and just missing this one piece for app side database.
And Thank you for all the wonderful work you and your team do. Appreciate!!!

@Tapac It's been a year now, I just wanted to ask if kotlin multiplatform support is on your roadmap now?

Well, a prototype of async support is coming to Exposed just now so my guess is that MPP support isn't coming any time soon.

@lbensaad , sorry, but I don't really have free time to dive into the native world. The problem is that I need to find the native drivers for each database and I'm not sure that there is a common interface such as JDBC in a native world.

It will be great if someone will try to contribute into the project in place of native support.

@Tapac For MMP sqlite is enough.

Just a note to say I came looking; interested in reusing some of my server-side Exposed Repository classes on the client across Android / iOS / Desktop (KMP). As @saied89 says, SQLite on iOS is the extend of the K/N support I'd be needing. Thanks for Exposed, it's a pleasurable API!

2 years have passed. I see this feature has appeared on your roadmap. It would be a good alternative to SqlDelight if it supports iOS

Is there any progress?

Hi
if Exposed support kotlin multiplatform (jvm, android, ios, wasm) then we write one code for server and sqlite cache database in client.
it's will be very easy to develop.
please get help and idea from sqldelight library.

Ktor 3.0 will support Kotlin Native.

It's time for Exposed to support Kotlin Native as well.

I faced exactly the same problem, while I was playing around with Ktor 3.0 (beta).
Until now there isn't any mature database driver that target the Kotlin Native.
Although, there quite a few projects that wrap a C driver, using FFI.

I did the same, I created a small driver, wrapping the sqlx driver from the Rust ecosystem.
If you want take a look here: https://github.com/smyrgeorge/sqlx4k

Would really love to see Exposed for KMP.
I much prefer it to room so I would use Exposed not only on server but in mobile apps too

is there any plan to have on Roadmap soon?

Hello, is there any plan to add support for KMP in the exposed-core package?
As I saw the only non-kotlin-native dependency is slf4j.
So, I guess will not be that hard (until the reality proves the opposite 😅).
If yes, I could then help with the implementation for the different DB drivers.
I could also help with the migration of the exposed-core module, but in that case maybe I'll need a bit of guidance.
As I mentioned in a previous comment I'm currently working on a database driver for Kotlin Native.

Very interessed in this, because I also want to work on an exposed over kotlinx.rpc. And additionally we could use exposed for ios development.

I need those three projects to be KMP:

• exposed-core
• exposed-dao
• exposed-kotlin-datetime

I've already looked into it, this should be possible, because the last two don't really have any other dependencies at all.

I will work on a pr which configures those build scripts to compile to kmp

Great news!
Whenever you prepare the PR I would also like to take a look.
Then I could start working with the driver integration (in the meantime I will take a look at exposed-jdbc module).

The driver that I'm currently implementing wraps the sqlx driver from the Rust ecosystem,
thus it only supports PostreSQL, MySQL and SQLite.
I think works quite nice and does not add extra overhead (that was actually my goal).

Sounds good, but I wanted to add that I'm not sure if I am even able to pull this off on myself, because currently I quite stuck on all those weird gradle plugin is applied or not applied or alrady applied, ... things. Quite discouraging, when considering the fact that I don't have really understood how gradle handles this all under hood. But I see it as an opportunity to learn something new, maybe I have luck and get it to work 🫠 keep my fingers crossed

Sure no problem. Also another problem is that Exposed does not support coroutines (at least for the moment).

I am also looking forward for a way to connect my K/N application to (a) database(s). During my search I found unixODBC project, which, although dated, seems to solve the connectivity problem. I was thinking to give it a go and use this, for my low level DB needs. @smyrgeorge do you believe the sqlx driver is a better approach, giving it supports less backends?

At any case, I believe it would be crucial to distinguish the low-level DB drivers from the high level API calls. This would be beneficial if other APIs, apart from Exposed, would like to emerge. Just how JDBC is doing. I really miss the lack of JDBC outside the Java ecosystem.

@teras I agree with your last comment. We need to distinguish the low level APIs. In my implementation I provide low level DB access plus Listen/notify for postgres. If you want take a look