I'm already quite excited about Turso being SQLite-compatible, but adding many features on top.
And when a feature is not directly compatible with SQLite (ie: you can't directly read the file with `sqlite3`, it's straightforward to convert). This is great because you know you'll always be able to continue working with that database. Even if Turso stopped working, it's still a valid SQLite database.
A combination I would be excited about is:
- Full support for Postgres protocol/wire format (ie: Postgres, but in-process, backed by a single file).
- Optional: Client/server architecture for further scaling and remote management using existing Postgres tooling
- All backed by a SQLite-compatible file
They are already adding MVCC to SQLite anyway. So their effort seems doable, and I hope they succeed.
Supporting Postgres is a good goal but honestly the real challenge is extensions. Would supporting Postgres wire compatibility guarantee any Postgres extension would also work? This is one of the problems with Aurora - it’s all well and good until you need an extension that isn’t on the blessed list
Author also discussing it on their Twitter [0]. I’m reserving judgement for now, but this has lots of potential usecases even apart from replacing postgres.
And when a feature is not directly compatible with SQLite (ie: you can't directly read the file with `sqlite3`, it's straightforward to convert). This is great because you know you'll always be able to continue working with that database. Even if Turso stopped working, it's still a valid SQLite database.
A combination I would be excited about is:
- Full support for Postgres protocol/wire format (ie: Postgres, but in-process, backed by a single file). - Optional: Client/server architecture for further scaling and remote management using existing Postgres tooling - All backed by a SQLite-compatible file
They are already adding MVCC to SQLite anyway. So their effort seems doable, and I hope they succeed.
[0]: https://x.com/glcst/status/2077759127682486561?s=46
at all