- Good Rust integration via async
- No multi-wal support
- Turso syncing is too limiting
- FTS engines just about the same
- Turso vector indexing times out
- Sqlite has proper concurrent writers
- Turso bought by Supabase
I been working on my shop management tool, Wenmar Pro, for a few months now. It was originally in Ruby on Rails and Sqlite. Because of the recent advancements in LLMs, it made sense to switch to Rust. In doing so, I felt like it made sense to try new tech, so there I saw Turso. A sqlite-compatible db rewritten in Rust. This is worth a look.
And so I’ve been running Turso for almost a month and have hit a few gotchas, which ultimately made me decide to move off it. It’s cool tech but after being burned from the past, I always take a hard look at the direction the project is going in. Are our values aligned? Who is funding this project? Self-funded? Internal tool? VC funded? Work is using this in production?
Almost all of the ground-breaking features are marked as experimental. Which means to me, it has some rough edges but it will work 99% of the time. This was not the case, like vector search doesn’t index after an hour (maybe it’s been fixed), or multi-wal writing corrupted my data.
Good Rust integration via async
Let’s start with a good point. Using Turso means your db calls in Rust are async. This is great for concurrency because Sqlite is only sync in Rust. This might be fixed in the future and it’s a major reason to use it. But it is a nice thing to have.
No multi-wal support
In Rails, it’s fairly common when deploying a new version of your app to have the app server running and then in the background boot up the new serer. In doing so, the new app server will migrate the existing db. This works fine with Sqlite but with Turso, it doesn’t because it only supports one reader at a time. This might be fixed in a future version. So one solution is to turn off the app serer, boot up the new one, migrate and then continue serving requests. This is definitely a downgrade but isn’t a deal breaker. One thing my llm mentioned is that there is experimental multi-wal support, which I asked it to turn on and test. And.. it failed, it corrupted the db. So I turned it off.
This is one nail in the coffin but isn’t totally a deal breaker. The point here is, it feels like every experimental feature in Turso is buggy. This doesn’t bode well.
Turso syncing is too limiting
So an other feature is the ability for Turso to sync down the db from a server to clients for faster reading. This feature just never fit into my app. It’s really just built for their own usage, and is too ridged for my case. Like you need to run their sync server on a separate port to use it. That won’t happen.
FTS engines just about the same
I originally thought because Tantivy is the FTS engine, it’ll improve on all the limitations of Sqlites FTS, like better fuzzy matching, ranking etc. It turns out their current implementation of FTS is half-backed. Here is a quote from my llm:
Turso’s documented FTS surface is exactly three functions — fts_match, fts_score, fts_highlight — with Tantivy powering it instead of FTS3/4/5. Tantivy the library does have FuzzyTermQuery with Levenshtein automata, but Turso’s SQL query syntax doesn’t expose fuzzy queries — so the typo-tolerance pain point you hit with FTS5 follows you to Turso. Your gem’s trigram approach (partial-token matching naturally tolerates typos) is actually the right technique in both engines.
It’s too limited and not a reason to switch to Sqlite.
Turso vector indexing times out
An article I found about vector indexing timing out. Not sure if it’s been fixed: https://marcobambini.substack.com/p/the-state-of-vector-search-in-sqlite.
An other nail.
Sqlite has proper concurrent writers
One major issue I had with sqlite was concurrency, my Rails app with background jobs running and requests coming in. I would get db lock errors once a day or so. Now that looks like a thing of the past with this recent work. see: https://substack.com/home/post/p-219562789.
Why use Turso now?
Turso bought by Supabase
The final nail is Turso being bought. This is where their whole plan makes sense, grow the project as fast as possible and worry about the details later. I think it’s a great product but from what I have seen, they took a shotgun approach by adding every cool feature to entice people to buy into them. Which I think has great potential, but ultimately all the cool features were half-baked. Multi-writer concurrency has severe limitations, like the requests have to be within a transaction (this prevented it from working in Rails, which I created a activerecord-turso gem for and tried to merged into their repo). Multi-wal is rough around the edges. FTS engine is too rudimentary for more advanced searches. Vector indexing is terribly slow.
Now that they got bought, their direction will change. It already looks like they are moving towards adding a Postgresql compatible interface. They’re biting off more than they can chew.
I’ll check back in in 6 months to a year.