With Turso you get an sqlite database behind a SDK or an (HTTP REST) API endpoint.
With Neon you get a postgresql database over a postgres wire format connection.
So if you have an already existing app speaking postgres to a database somewhere, Neon is a drop-in-replacement, while Turso would require adapting to their custom API.
If you are creating a new service, you might need/want to take advantage of e.g postgres extensions [0] for storing geographical data or pg_vector for similarity searches etc. Or you simply need more stringent serialisability promises than what libsql / turso can provide.
But if you just writing something new from scratch and have "simple" demands, I think something like Turso looks cool (and cheap!).
With Neon you get a postgresql database over a postgres wire format connection.
So if you have an already existing app speaking postgres to a database somewhere, Neon is a drop-in-replacement, while Turso would require adapting to their custom API.
If you are creating a new service, you might need/want to take advantage of e.g postgres extensions [0] for storing geographical data or pg_vector for similarity searches etc. Or you simply need more stringent serialisability promises than what libsql / turso can provide.
But if you just writing something new from scratch and have "simple" demands, I think something like Turso looks cool (and cheap!).
[0]: https://neon.tech/docs/extensions/pg-extensions