Turso Blog

As you might know not one tool fits all, I still have strong preferences for the following. It helps me get going faster and get things done right first time and helps in ease of maintenance.

Language: Typescript.

Frontend Framework: Astrojs [1] or qwik [2]

Frontend Library: React if it requires 3d and other frame-motion like animations, else will not use any frontend library or might throw solidjs if required for some state etc.

Backend: Cloudflare functions, google functions

Auth: Lucia-Auth [3] if required

IDE: VS code with neovim , once deployed to git, I might some time use code-spaces

CSS: DaisyUI [4] with tailwind or Bulma

CSS Library: TailwindUI [5] makes most of the components ready to use and comes from the makers

CMS: Astro content collections or Sanity [6]

Deployment: Cloudflare (Highly preferred) or linode/digitalocean/netlify

Database: turso [7] or neon postgres [8] with (drizzle orm) or cloudflare durable objects

1. https://github.com/withastro/astro

2. https://github.com/BuilderIO/qwik

3. https://github.com/lucia-auth/lucia

4. https://github.com/saadeghi/daisyui

5. https://tailwindui.com/

6. https://www.sanity.io/

7. https://turso.tech/

8. https://neon.tech/

Also huge fan of firebase and their emulators and whole eco-system.

> The language design contract is unsafe by default

False. The language design safe by default, something that you can confirm super easily doing just the Rust tutorials and compare the same with C or C++.

Read the repo well:

cve-rs implements the following bugs in safe Rust:

Use after free
Buffer overflow
Segmentation fault

NOT REFUTE IT.

> There are unsafe blocks all over the stdlib

Unsafe blocks is not the same that unsafe code. Are marked areas that are required to do escape automated checks, and there, you are at the level of a C/C++ programmer (where in that languages ALL THE CODE IS MARKED UNSAFE).

If you complaint against that, is the same as complaint against ALL THE CODE writer on C/C++.

---

One thing important to understand about Rust: Rust is a system language and SHOULD be able to implement everyting including, Buffer overflow, Use after free , Segmentation fault and such. You should be able to implement a terrible OS, malware, faulty drivers, etc, minimally because that is required to test safe programs!

(example: Deterministic Simulation Testing https://turso.tech/blog/introducing-limbo-a-complete-rewrite-of-sqlite-in-rust).

But what Rust gives is that not assume that you want to do it for most programs.

> However, it's only meant for local systems. Once you need to connect over a network or robustly handle simultaneous requests

That’s not really accurate any longer.

Mostly depends on how you layout your tables & files. If you shard the databases then multiple machines can act as writers for their shard. You can also split read requests from write requests and have read only machines scale up/down as much as you’d like. You can use multiple files in a query (there is a limit there).

So for example you can split the user table based on the first letter of the username and then depending on the rest of the database either a database file per user or per customer (organization). Of course more of everything is manual but it’s not as hard as you’d expect if you build for it.

https://rivet.dev/blog/2025-02-16-sqlite-on-the-server-is-misunderstood/

If you need sqlite over the network you can look at https://turso.tech/ it’s a almost drop in replacement for sqlite (https://github.com/tursodatabase/turso/blob/main/COMPAT.md)

I am a pretty serious "Rustacean", but I like to think "for the right reasons". A rewrite in Rust of the main project would make very little sense, unless there is some objective the project wants that can't be met with C (see below). This person presents a well thought out case on why it makes little sense to rewrite, especially in the final section. Rust is great for many things, but when you have something old that is already so well tested and accessible on all sorts of obscure platforms, it makes little sense to rewrite, and the likely result would be more bugs, not less, at least in the short term.

All that said, some have found reasons to rewrite in Rust, and are currently working on that: https://turso.tech/blog/introducing-limbo-a-complete-rewrite-of-sqlite-in-rust

This presentation is focused on the use-case of vertically scaling a single server and driving everything through that app server, which is running SQLite embedded within your application process.

This is the sweet-spot for SQLite applications, but there have been explorations and advances to running SQLite across a network of app servers. LiteFS (https://fly.io/docs/litefs/), the sibling to Litestream for backups (https://litestream.io), is aimed at precisely this use-case. Similarly, Turso (https://turso.tech) is a new-ish managed database company for running SQLite in a more traditional client-server distribution.

Their goal is to run this on their own cloud.

Despite their lofty claims about community building, their projects are very much about forwarding their use case.

Given that SQLite is public domain, they're not required to give anything back. So, it's very cool that they're making parts of their tech FOSS.

But I've yet to see anything coming from them that isn't “just because we need it, and SQLite wouldn't do it for us.”

There's little concern about making things useful to others, and very little community consensus about any of it.

https://turso.tech/