[polyrand]

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.

[SOLAR_FIELDS]

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

[amluto]

There’s a section about extensions in the FAQ.

[lmz]

> Would supporting Postgres wire compatibility guarantee any Postgres extension would also work?

It would not, for obvious reasons.

[SOLAR_FIELDS]

Care to elaborate? The reasons are not obvious

[dumah]

Wire protocol applies to external interaction with the db.

Internal ABI/API is used by extensions to directly interact with core subsystems and depends on internal models for things like storage.

It might be analogous to HTTP versus an nginx plugin.

[SOLAR_FIELDS]

curious how hard it is to implement wire protocol compatibility vs the internal api surface. Are we talking like, an order of magnitude more work here? I wonder if, for example, Aurora team are literally maintaining forks of extensions for their implementation and that's why only a subset of all possible extensions are supported?