3 ms·
Turso is sqlite not postgresql
by johtso 2y ago
Turso is sqlite not postgresql
- yawnxyz 2y agoas a "mere user" of the JS or API endpoints, should I think one is better than the other? To me it doesn't really matter if it's Supabase/Neon, Turso, or D1 powering it as long as... it works Is this faster / more resilient?
- djha-skin 2y agoI'd probably care because of the ecosystem. There's a bunch of developer tooling and mature ORMs around postgres. Granted, those same libraries/frameworks probably work with sqlite too. I guess it's just trust. I trust postgres more than I trust sqlite for building big apps. One last point: I'd look at feature set of both offerings. I suspect the features of the postgres offering to be more conducive to scale.
- nop_slide 2y agoThey both could be faster or more resilient depending on your workload and what you want that to mean. Take some time to learn about the differences between postgres and sqlite it is good to know about the trade offs.
- filleokus 2y agoWith 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!). [0]: https://neon.tech/docs/extensions/pg-extensions https://neon.tech/docs/extensions/pg-extensions