Turso is an database for the edge, which is why it departs from how most databases operate. First and foremost, Turso works both locally and remotely by relying on libSQL, our fork of SQLite. When working remotely, the database is accessed through HTTP and WebSockets, as opposed to a traditional TCP-based wire protocols, which makes Turso accessible from almost any environment, including edge functions.
But also, we’re developing Turso control plane as a REST API because we believe infrastructure should be programmable. In fact, early on, we made a decision to make the whole UI initially just be a CLI, to make sure we didn’t take short-cuts in the API design. Of course, we’re planning to add a web UI down the road, but the current developer experience with just a CLI is surprisingly smooth and simple!
We also put a lot of thought in Turso to make the creation and operating geographically dispersed replicas easy, so you can, for example, programmatically create a replica in Australia when you see increased traffic coming from that area and destroy it right after. The CLI plays the role of a reference implementation for the API, and together with the reference documentation that we plan to publish soon, should help developers understand how to integrate Turso database operations into their workflows.
But there’s a more fundamental reason to making the CLI open source: we strongly believe in the transparency and hackability that open source brings. In fact, the replication code for libSQL and rest of the data plane that powers Turso’s replicas is all open source, and we intend to keep developing new features in the core database in open source because as Glauber, the CEO my co-founder keeps pointing out: it’s just in our DNA. That’s also why sponsoring Drizzle and working with the team towards bringing a great experience with Drizzle on Turso.
So with that out of the way, go check out the Turso CLI on Github:
If you have questions/comments/bug reports, please drop by our Discord or leave an issue on Github!