Turso is an in-process SQL database, compatible with SQLite

Posted by marklit 5 days ago

Counter141Comment99OpenOriginal

Comments

Comment by d1l 2 days ago

I’d imagine there’s an extremely long tail of features and quirks that will take time to iron out even after SQL compatibility is achieved. Looks like it’s still missing some important features like savepoints (!!!), windows and attach database.

I’d be more excited and imagine it would be more marketable if it focused instead on being simply an embedded sql db that allowed multiple writers (for example), or some other use case where SQLite falls short. DuckDB is an example- SQLite but for olap.

Comment by Joker_vD 2 days ago

There is. For example, four months ago [0] they've accidentally stumbled upon about an explicitly documented quirk of SQLite file format.

[0] https://news.ycombinator.com/item?id=45101854

Comment by hiddendoom45 1 day ago

I stumbled on the lock page myself when I was experimenting with writing a sqlite vfs. It's been years since I abandoned the project so I don't recall much including why I was using the sqlitePager but I do recall the lockpage being one of the first things I found where I needed to skip sending page 262145 w/ 4096 byte pages to the pager when attempting to write the metadata for a 1TB database.

I'm surprised they didn't have any extreme tests with a lot of data that would've found this earlier. Though achieving the reliability and test coverage of sqlite is a tough task. Does make the beta label very appropriate.

Comment by tracker1 1 day ago

I think that async support for multi-read(and write) are part of the reason for the separate Turso library in Rust over the C fork (libSQL). I also wouldn't be surprised if baking in better support for replication was a design goal as well. Being file-format compatible with SQLite is really useful as well.

In the end, the company is a distributed DBaaS provider using a SQLite interface to do so... this furthers that goal... being SQLite compatible in terms of final file structure just eases backup/recovery and duplication options.

I think being able to self-host either in an open/free and commercial/paid setting is also going to be important to potential users and customers... I'm not going to comment on the marketing spin, as it is definitely that.

Comment by ncruces 1 day ago

You're only file format compatible if you don't use any of the Turso extensions.

Just like STRICT tables, as soon as you use an unsupported feature in your schema, your database becomes incompatible.

With STRICT tables you needed to upgrade SQLite tools.

But if you use something from Turso you're placing yourself outside the ecosystem: the SQLite CLI no longer works, Litestream doesn't work, sqlite_rsync doesn't work, recovery tools don't work, SQLite UIs don't work.

Turso has no qualms with splitting the ecosystem. They consider themselves the next evolution of SQLite. The question is do you want to be part of it?

Comment by ako 1 day ago

I've been using a sqlite alternative to avoid dependencies on a native library. It's go application that uses a native go sqlite reimplementation so i can create platform specific binaries that include all dependencies. Makes installation easier and more reliable.

Comment by formerly_proven 1 day ago

modernc.org/sqlite is upstream SQLite, compiled to Go using ccgo. Spiritually similar to, say, a WASM build of SQLite. Not a separate reimplementation.

Comment by ako 1 day ago

Aha, wasn't aware, good to know, thanks.

Comment by ncrmro 1 day ago

I’ve been using it locally and with their hosted offering for awhile now and it’s rock solid other than if I make super deeply nested joins which overflow something. But other that that it’s super fast and cheap I haven’t had to need more than the free tier with a bunch of stuff I host on cloudflare workers

Comment by maxpert 1 day ago

Disclaimer: I am author of Marmot https://github.com/maxpert/marmot so I will sound extremely bias.

I have been asked multiple times on why I chose SQLite and not Turso. I've always responded people that I don't trust an open-source project once it's backed by a VC firm. I've moved away from Redis to Val-Key for same reason, and we have seen the Redis train-wreck in slow-mo. I hope at no point in future Turso ever ends up in that state, but chances are pretty high. At this point the "compatible with SQLite" has become a marketing term IMO, we all know how easy it is to break compatibility here or SQLite to break compatibility.

Comment by bawolff 1 day ago

I find it crazy that people would ask you in that direction. I would wonder why anyone would chose Turso over SQLite.

SQLite is some of the most battle tested software in the world. Turso seems like relatively new software that is still a bit experimental.

You do not want your databases to be new or trendy. You want your databases to be solid as a rock.

Comment by anentropic 1 day ago

> I would wonder why anyone would chose Turso over SQLite

well, Turso adds features

otherwise yeah, there'd be no reason

Comment by namibj 1 day ago

Ok, `io_uring` (like NVMe but for IO commands from application to kernel) and DBSP (high-grade framework for differential (as in, based on Delta streams/diffs not full updates) compression of "incremental view maintenance", it can keep materialized views synchronously up-to-date with a cost proportional to just the diff (for most typical ones; certain queries can of course be doing things at an intermediate stage that blow up and collapse again right after)).

At least notably; not sure about the MVCC `BEGIN CONCURRENT`'s practical relevance though; I am just already familiar enough with the other two big ones to chime in without having to dive into what Turso does about them...

Comment by bawolff 9 hours ago

> Ok, `io_uring` (like NVMe but for IO commands from application to kernel)

Are there benchmarks comparing turso with io_uring to sqlite (with other config the same)?

io_uring has the potential to be faster but its not garunteed. It might be the same, it might be slower, depending on how you use it. People bragging about the technology instead of the result of using the technology is a bit of a red flag.

Comment by jauntywundrkind 1 day ago

Sqlite had such a stellar stellar reputation, for so many excellent reasons.

I still find it absolutely freakish & abominable that people are so incredibly touchy & reflexively mean & vile to Turso. I've seen a couple Turso centric YouTube's recently and there are dozens and dozens of up votes for what just seems like the most petulant vacuous reflexive bitter viewed comments, dominating the comments. Sqlite deserves its honor, is amazing! Yes! But there's such a wild concentration of negativity about a sqlite compliant open source rust rewrite. None of it is technical. It's all just this extreme conservatism, this reflexive no, I don't trust it, fud fud fud fud.

(Can't find the worse example but https://youtu.be/CrIkUwo8FiY somewhat shows this)

I'm just so embarrassed having such low antagonistic peers dominating the conversation all the time. With zero moderation, zero maybe it's ok, just dialed 100% to no no no no. For fuck sake man. Everywhere I go it's not hackers, it's not possibility seekers, it's a radical alliance of people using fear uncertainty and doubt to cling to some past, refusing even possibility of different. It's so regular, so consistent, so tiresome and so useless.

What if this is better? What if you are wrong? What if there is some possibility of better? It just feels like all the air time is sucked up by these negative creeps, always, everywhere, all around, with these absurd vast pervading pessimisms that admit to no maybe possiblies, that see no tradeoffs, that are just convinced always for the worst. And it's just so popular! Is the plurality! How anti-hackerly a spirit is anti-possibility! The world deserves better than these endless drag-gards.

I'm obviously reacting strongly here. But I just want some God damned room left for maybe. The negative creeps never allow that: no no no no no, fear uncertainty & doubt endless & abundant, no possibility, just bad. I cannot stand the negative energy, I'm so sad the hackers have to put up with such absolutist shitty drains sucking all the energy from the room, everywhere, always. Sqlite somehow has such a strong anti-possibility anti-energy magnet around something so so good: what a shame, it deserves better, & iteration attempts deserve at least some excitement. Progress is possible, can be neat, and judging way too early & reflexively with empty comment is to be condemned, imho.

Comment by rendaw 1 day ago

I definitely feel this. So many "I made an alternative to X that fixes these issues, or is better in these ways" met with "Well X is fine for me, and I don't need those things, so why change?" These posts are obviously meant for adventurers, people looking to improve on the status quo, have some experimental budget left, etc.

Reading the repo, I'm not sure what it offers. It's still CGO for Go (edit: it's not, it's purego, but can that be used for SQLite too?), Rust already has `rusqlite`. It's beta, so it doesn't have stability, and 99% of why I and many other people choose SQLite is stability.

But they bluntly say you should use it instead of SQLite: "The next evolution of SQLite" (trademark ok?). This not only implies that SQLite has some significant design issues that merit a new version, but it also implies that they, not the SQLite author, are the ones who are capable of doing this. My guess is this is what's rubbing so many people the wrong way.

It's not being sold on its merits, and I think if they're going to make that sort of statement it's fair to make the standard somewhat high. If it's an AI-oriented database, sell it that way, not as an SQLite replacement.

I don't think uv had a negative reaction, because it had a really compelling case.

Comment by tracker1 1 day ago

The way I see it there are a few goals for Turso as opposed to SQLite...

One is to be more open to contribution, which is of arguable value for a pretty "complete" project.

Another is to be able to better support a client-server and distribution model for resilience over only in-process options, which is harder. This is while being file compatible with SQLite for the database itself.

Another aspect is multi-threaded support (mutli-read in particular), which is part of the impetus for rewriting in Rust over the fork, for what may well be a dramatic performance improvement.

Cloudflare and Turso as companies are both using SQLite's interfaces and structure at a core piece of their distributed database offerings... There's definitely different characteristics for use/scale if you're going that route. I've also found CockroachDB to be interesting along with the now deprecated RethinkDB's approach. That doesn't even get into the more prominent distributed cloud db options out there.

In the end they're all just different approaches to solving similar issues.

Comment by HelloNurse 1 day ago

If you think this discussion is antagonistic, you should see how antagonistic "entrepreneurs" and VCs become when they are in charge of open source projects. Risk aversion is good.

In this case, the familiar "rewrite it in Rust" MO has a special angle: the Turso feature list is such a terrifying collection of high-risk, low-performance, inferior, unlikely to be compatible, unproven and unnecessary departures from SQLite that a malicious embrace-and-extend business plan is a reasonable theory and reckless naivety is the best possible case.

Comment by bawolff 1 day ago

> What if this is better?

If it was actually better you would probably be describing how and why you think its better instead of complaining about "negativity".

Comment by jauntywundrkind 1 day ago

Pretty good vector processing built-in. Time series capabilities. Nice Change-Data-Capture table that I've used & loved. Rust which is easy as hell to embed. Underlying libsqlite is very useful too. The CLI has far better ergonomics than sqlite & good formatting. Async & concurrent writes. Backwards compatibility. Just so ragingly badass. Tries. Isn't narrow & conservative. Amazing test suite.

The discussion didn't seem to be about merits. It just simply seemed to be a bunch of pissy empty whining & loser statements that it wasn't even worth beginning to regard it at all, for dumb petulant reasons x y and z. Fuck that. Fine, I'm happy to sing some praises. But IMO there is a war against imagination & this loserly attitude is the omni present all pervading no value woeful forefront. This pox is everywhere, just no regard, no consideration at all, just out of hand disregard for ridiculous inconsiderate Fear Uncertainty and Doubt anti-reason, thought terminating no's.

Murderers of hacker spirit. Sure, come ask for better! Yes!! Please!!! Inquire & challenge. Push for actual meat (both ways). I saw none, I tried to give you some here. These empty vessels have just vapors of fear, boogiemen to conjure & scare with. No actual content or assessment. So weird to rally so hard against open source, just because it doesn't also hail from 2.5 decades ago. We need more than reflexivism. Or we are shite non hacker people of a low culture.

I complain about negativity because this is rotten & a stink. It's everywhere & so rarely is it of substance, talks to anything. I've tried to add some weight here, and most of what I've said feels basic but this gets bold: I think the weight of anti-possibility weighs heavier & has a bigger mantle to bear in its naysaying than speaking for. We should attune ourselves to consideration. The hacker spirit should favor the idea of possibility above rejection & discarding of potential.

Comment by bawolff 1 day ago

> Amazing test suite.

Lol, is that a joke.

Seesh.

[To be clear, i think sqlite is the hands down winner on this front, no contest. Does the Turso test suite qualify it to be used in safety critical applications? I don't think so].

To your other points - look if it works for you i'm not here to tell you you can't use it. However these features sound more trendy than useful. To me these sound like negatives. A bunch of extra features not related to being a relational database suggests they aren't concentrating on the core product. I dont know enough about their model for async & concurrent writes to really evaluate the cost/benefit, but both those features sound potentially really scary and of questionable value.

At the end of the day its just not a compelling pitch. It seems like trading reliability and stability for a bunch of meaningless bling.

Best of luck to them, but at this point yeah, sqlite sounds like a much better option to me.

Comment by tracker1 1 day ago

Have you seen the SQLite test suite? AFAIK, it's private/secret/closed. I think that is a part of the argument against SQLite.

Comment by bawolff 17 hours ago

Do you usually read test suites?

I care that sqlite is being tested against it, because i care that sqlite is well tested. i'm not super concerned that part of the test suite is closed source as i dont need to directly use it.

Comment by jauntywundrkind 1 day ago

It's just so wild to me that people are so married to anti-features like this. That anti-interest do possesses the modern spirit, enraptures people so.

'i don't know what it is but I'm not interested and it's probably scarey' is not, imo, befitting the cultures I personally want to see. There's times and places for extreme conservatism, but generally I am far more here for progress, for trying for aspiring to better, and I thought that was so clearly what the hacker spirit was about.

Comment by HelloNurse 1 day ago

Progress would be a respectful experiment to hack an implementation of vector indexing, or some other actually useful feature, into the actual SQLite, preferably as an extension.

That would be a valid experiment and, if it goes well, a contribution, while hoping that someone bases anything important on Turso looks like grabbing captive users.

Comment by dgroshev 1 day ago

It's pretty easy to get some hard data, it's an open source project. I went to https://github.com/tursodatabase/turso/pulls?q=is%3Apr+is%3A... and looked at the last few PRs:

https://github.com/tursodatabase/turso/pull/4824/files "some performance improvements", no new tests

https://github.com/tursodatabase/turso/pull/4820/ "fix wal checkpoint", one basic test

https://github.com/tursodatabase/turso/pull/4815/ "Optimizer: fix bugs, improve cost model", a lot of nontrivial logic, no new tests

https://github.com/tursodatabase/turso/pull/4814 "WAL auto truncation: increase epoch to prevent stale pages reuse", there's a new test with a comment "It is slightly fragile and can be removed if it will be unclear how to maintain it"

https://github.com/tursodatabase/turso/pull/4806/ "Busy snapshot bugfix" with two new tests with the same comments as 4814 (I guess they didn't fix the bug in one go?)

https://github.com/tursodatabase/turso/pull/4802/ "fix/translate: revert change that allowed index cursor with stale position to be read", fixes a data-corrupting bug, there's a regression test, good (although the original bug sounds like it should've been caught by a suite like the one SQLite has)

That's just a couple days worth of PRs.

This style of development does not inspire confidence. They develop features, sure. But I want my database to be rock-solid and completely covered by tests, not just move fast and break things. It's not FUD to just look at how they approach PRs.

Comment by aranw 1 day ago

Which SQLite Go library do you use? My biggest pain with using SQLite in Go is often the libraries and the reliance of CGO which is what puts me off using Turso

Edit: Looking at the go mod file I noticed github.com/mattn/go-sqlite3 which I think is a C wrapper library so I'm assuming you rely on CGO for compiling

Comment by ncruces 1 day ago

You have at least 2 alternatives that don't require CGO (disclosure, I made the second one):

https://pkg.go.dev/modernc.org/sqlite

https://pkg.go.dev/github.com/ncruces/go-sqlite3

Comment by cmrdporcupine 1 day ago

So then the follow-up question to that is:

How can we make sure that fundamental pieces of open source software that power the Internet can have funding, and that the people who write them can have comfortable lives working on the piece of software they love that so many people use?

I think you've described a real problem. But people turn to VC because there are few other ways to make funding happen.

Comment by deaux 1 day ago

Didn't have a good experience with them. One day we suddenly started to experience severe latency spikes, lasting for more than a day, causing timeouts. Unrelated to our DB which was small, even happened on trivial queries - a networking thing on their side. Google showed this to have happened before with certain regions of theirs. If you can't offer a certain region in a stable manner as a DB vendor, don't offer it. The whole point of outsourcing DB mangement is to take care of these things.

Comment by cortesoft 1 day ago

I am confused, this product appears to be an in-process DB, so what does "networking thing in their side" even mean?

Comment by memothon 1 day ago

Turso offers a cloud-hosted sqlite product. The idea is you can easily spin up per-tenant databases and have a "serverless" sqlite interface.

It feels like it has a lot of the same downsides of hosted databases so I'm not sure what the specific value is.

From their site they really emphasize local first syncing (so mobile apps and electron/tauri apps) and multi tenancy (hard database boundaries)

Comment by TheCapeGreek 1 day ago

Honestly I still don't understand how "cloud sqlite" isn't an oxymoron.

I get it, Turso wants to actually make some money, but I just don't get it.

Comment by oofbey 1 day ago

Huh. That sucks but also isn’t surprising. Seems like putting this in the cloud eliminates most of its benefits though. If you’re going to wait for that much latency you might as well use a “real” (traditional big complicated) rdbms.

Comment by sudhirb 1 day ago

For me, a lot of the draw is that it's cheaper than managed db services for small/toy projects of mine (that I don't want to use dynamo db for) - that and in a previous job it was useful as relatively temporary multi-tenant storage.

Comment by deaux 1 day ago

Sorry, the other replier is correct, it was about their cloud offering.

Comment by loloquwowndueo 2 days ago

But I thought turso already had an SQLite-compatible thing, libsqlite!

Turns out this is covered in the readme: libsqlite is a fork (so, presumably C) while turso database is a rust rewrite.

Good luck to the friends at Turso!

Comment by redwood 1 day ago

Is there an example of a company that rewrote something popular in a faster / better language and built a successful business on that? I can think of ScyllaDB and Redpanda but aren't they struggling for the same reasons: not the default, faster horse, costly to maintain, hard to reach escape velocity

Comment by graerg 1 day ago

You could make the case uv falls in this category (I just prefix all my pip commands with uv) though we have yet to see if astral will become a "successful business"; I'm hoping they pull it off.

Comment by gpm 1 day ago

I feel like there's numerous database companies that rewrote an existing database faster/with slightly better features and turned it into a successful product. Just about all of the successful ones really. It's a market where "build a faster horse" has been a successful strategy.

Certainly some of the newer succesful database companies are written in more modern languages (for example go with cockroachdb, go originally and now rust with influxdb) but it's wrong to call these (or really any language) faster than C/C++ just more productive languages to develop reliable software in...

Comment by redwood 1 day ago

I agree you see there's a lot in the database space I just don't know many have reached escape velocity more often they've raised a bunch of venture capital funding and plateau and then have a big problem

Comment by gpm 1 day ago

I have an impression that the two I named (cocroachdb, influxdb) are actually commercially successful, but I could be wrong.

Comment by thayne 1 day ago

I'm not sure how big of a factor it is, but scylla and red-panda are both source available, and VC funded, while the projects they are trying to replace are fully open source, and owned by a non-profit foundation. That probably isn't the only reason they are struggling, but it is a potential reason not to switch.

Granted, scylla used to be open source. And turso is VC funded and potentially vulnerable to a license change in the future.

Comment by kleton 1 day ago

A gotcha, if you are expecting compatibility with sqlite. You can't set PRAGMA journal_mode=WAL and expect to be able to read database state from another process. Turso will report exclusive lock

Comment by sealeck 1 day ago

I thought the point of Turso was to offer better concurrency than SQLite currently does. A la https://turso.tech/blog/beyond-the-single-writer-limitation-... and https://penberg.org/papers/penberg-edgesys24.pdf

Would be great if one of the Turso developers can clarify :)

Comment by bawolff 1 day ago

Honestly, if you care about that level of concurrency, it begs the question of why are you using an in process database in the first place?

Comment by sealeck 23 hours ago

It's not just about performance: having an in-process MVCC engine would simplify the implementation of many single-machine concurrent applications. Currently you usually have to combine SQLite with some kind of concurrency primitives; this is extremely painful because most OS-level concurrency primitives are really easy to misuse (e.g. it's trivial to accidentally add deadlocks, and very hard to spot and remove these ahead of time: example hard to spot concurrency bugs https://fly.io/blog/corrosion/, https://rfd.shared.oxide.computer/rfd/400)

Comment by miohtama 1 day ago

One reason is that architecture and maintenance are much simpler

Comment by heyts 1 day ago

This looks like a solution in search of a problem already solved by SQLite

Comment by thayne 1 day ago

I think the problems with sqlite:

- sqlite can't do concurrent writes, which is a performance bottleneck for certain workflows

- sqlite is synchronous, which isn't ideal in applications that are async

- while sqlite itself is open source, the test suite is proprietary, which means forking it and adding your own features or bug fixes isn't really practical. Of course, that is also a significant barrier to turso having sqlite compatibility.

Does turso really solve those problems? IDK. Does it introduce new problems? Almost certainly. But those are real problems that people have.

Comment by gritspants 1 day ago

Proprietary? Are you referring to the test suite they created for avionics that last I checked they've never really sold? I think it's highly misleading to make that claim if so.

Comment by thayne 1 day ago

I thought most of the test cases were proprietary, but it looks like you are right and it actually is just the TH3 test suite, and the fuzzer.

Comment by Sytten 1 day ago

When it is ready for production and they implemented DDL to alter tables that D. Hipp just refuses to implement for some reason then I am in. People that feel attacked by this didn't have to deal with the antagonist behaviour of SQLite maintainers toward the community.

Comment by 1 day ago

Comment by 1 day ago

Comment by 1 day ago

Comment by rpcope1 1 day ago

How many times is this going to get shilled? It shows up at least once a month and the people associated with come in talking like it's almost trivial to "build a better sqlite" or that in essence SQLite3 is "deprecated." Give me a f**ing break.

Comment by blibble 2 days ago

the description as "the next evolution of sqlite" is offensive

D. Richard Hipp has done a universal good for the world by releasing sqlite into the public domain and maintaining it for 25 years

I bet this VC funded knockoff won't see 5

Comment by gpm 2 days ago

> the description as "the next evolution of sqlite" is offensive

That marketing is really the one thing that keeps me from considering this as a serious option.

To callback to an article a few days ago, it's a signal of dishonest intent [1], and why in the world would I use the alternative built by apparently dishonest people when sqlite is right there and has one of the best track records in the industry.

[1] https://zanlib.dev/blog/reliable-signals-of-honest-intent/

Comment by egorfine 1 day ago

In the early stages I have seen this project being referred to as "sqlite rewrite in Rust" which is untrue and dishonest at multiple levels.

Pure stolen valor.

Disgusting.

Comment by renewiltord 1 day ago

[flagged]

Comment by anitil 1 day ago

It warms my cold heart every time I open up an sqlite file and read -

> May you do good and not evil.

> May you find forgiveness for yourself and forgive others.

> May you share freely, never taking more than you give.

Comment by krior 1 day ago

That's no ethical code, thats just religious fluff.

The tenants my comment-neighbour quoted are a much better example.

Comment by gjvc 1 day ago

we are moving from a world of "tenets" to a world of "tenants" yes

Comment by beyondCritics 1 day ago

They are giving their stuff away for free, hence they can do whatever they want. It goes without saying, that spiritual teachings are not there to create quarrel and division.

Comment by renewiltord 1 day ago

The Trojans did the same. Beware the man who has no morals. His kindness could be cruelty disguised.

Comment by elemdos 1 day ago

Ohhh is that why their logo is a bull?

Comment by IshKebab 1 day ago

I'm very happy for my software not to come with religious proselytising.

Comment by tonyhart7 1 day ago

offensive ???? bro its just marketing headline, nothing deep at all

Comment by doodlesdev 1 day ago

SQLite is public-domain software and one of the best well-maintained pieces of software around today. You absolutely have to be very careful before saying things like these, as they bring lots of implications. I wouldn't call it offensive _per se_, but I'd say it's in bad faith at least. I'd just remove that if I were the devs, because everything else there makes me find the project at least interesting.

Comment by feverzsj 1 day ago

Without SQLite's full test suit, I don't think it's as safe. Rust may have better memory safety, but that's just part of the issue.

Comment by rzmmm 1 day ago

They can probably use most of SQLite test suite.

Comment by feverzsj 1 day ago

Except the most critical of them are close-sourced.

Comment by XorNot 2 days ago

I'm confused why I would use this when Sqlite exists?

Being written in Rust it's not even a good libc-less drop in choice for a language like Go?

Comment by mattrighetti 2 days ago

One quick thing I can think of is multiple writers [0]

[0]: https://turso.tech/blog/beyond-the-single-writer-limitation-...

Comment by ZeroCool2u 2 days ago

This is a huge differentiator. I built our internal meme platform with Turso. Really fun and easy to use.

Comment by zdragnar 2 days ago

How much internal traffic are you generating that single thread sqlite writes can't keep up?

Comment by ZeroCool2u 1 day ago

The meme machine cannot be stopped. It's really not that much, but this has the nice side effect of I simply don't need to worry about it.

Comment by ncruces 1 day ago

What's the isolation level? They only mention write-write conflicts.

The reason SQLite's BEGIN CONCURRENT does not greatly increase concurrency (unless you're very careful with your schema and queries) is as much due to page level conflict detection as it is because it enforces serializable isolation.

Comment by tonymet 2 days ago

isn't this just pushing the complexity around? Either my write thread manages the lock, or turso's does.

Comment by gpm 2 days ago

MVCC is a non-locking algorithm for concurrent writers that the big databases like postgres use (with caveats like aborting some transactions if conflicts would exist). It's not a matter of pushing locks around but allowing multiple threads to operate on the data concurrently.

Comment by tonymet 2 days ago

thanks helpful thanks. seems to have some tradeoffs. I would likely lean toward the simpler thread model but it sounds compelling.

Comment by netghost 1 day ago

It natively supports vector embeddings, which seems like it could be nice. The sqlite extensions I've tried for vector embeddings have been a challenge to get working (may just be me though).

Comment by loktarogar 2 days ago

> Turso Database is a project to build the next evolution of SQLite in Rust, with a strong open contribution focus and features like native async support, vector search, and more

Comment by everfrustrated 1 day ago

The entire reason behind Turso is that the author had a beef with the sqlite people.

Comment by kobieps 1 day ago

Hopefully anything useful and stable in turso will be ported to sqlite

Comment by pdyc 1 day ago

what is wasm size? how difficult is it to use in webapp? and does it allows udf's? in sqlite its quite easy to create udf.

Comment by rednafi 2 days ago

Turso is sqlite with a server client arch. I use them for stashing my llm usage logs all the time. Pretty neat. Plus I'm rooting for them to rewrite sqlite in Rust.

Comment by MobiusHorizons 2 days ago

If it is in-process (as the article says), why do you describe it as client / server architecture? If it’s not in-process why compare it to SQLite instead of other client server databases like Postgres?

Comment by rednafi 1 day ago

There is turso cloud.

https://docs.turso.tech/turso-cloud

Comment by qeternity 1 day ago

What is the point of this?

Comment by heliumtera 2 days ago

Commit history is nuts! These guys are working.

Comment by menaerus 1 day ago

It goes to show how future of SE will look like. Loose reviews (a big win for the industry) with each person capable of doing 10x more work, and basically orchestrating/overlooking the work done by the agents. The bottleneck eventually at some point, if not already, will become a fatigue caused by having to process/acknowledge/understand the sheer volume of code spitted out at speeds that we could never have imagined before.

Comment by heliumtera 1 day ago

If you are doing loose reviews I guess you're not strictly more productive, because this would be a different kind of work...a more "loose" work, but a scalar I'm volume.

Comment by menaerus 1 day ago

Loose work? No, quality of work being done does not correlate with reviews in almost any way, unless you're a lousy engineer doing lost work anyways. High quality reviews are exceptionally rare.

Comment by gritspants 2 days ago

> AGENTS.md

Claude is that's for sure

Comment by leosanchez 1 day ago

No dotnet client ?

Comment by mergisi 5 days ago

[dead]

Comment by doanbactam 1 day ago

We switched our main API from Postgres to Turso last month and haven't looked back. The automatic schema migrations are a nice touch, but I wish the documentation on vector embeddings was a bit more robust. It's wild how much of the modern web is moving back to file-based databases. We switched our main API from Postgres to Turso last month and the cold start times are basically zero now. Are there any plans to support vector columns soon, or is that strictly off-roadmap for now?

Comment by eddythompson80 1 day ago

You had a cold start issue with Postgres? Were you running a serverless postgres?

Comment by killingtime74 1 day ago

You only run a single instance of your API? How many monthly customers do you have

Comment by oofbey 1 day ago

How do you scale your front end horizontally with a file based database? Do you put the files on a shared file system that the app layer all mounts and lock when writing? Or do you shard and route by user? Or do you build a big vertically scaled API server with the database in it?

Comment by tracker1 1 day ago

There's a few options... they could be using separate database instances per client to isolate workloads... if there are fewer than 10k or so users at each client, it's pretty doable without a lot of effort, you can further isolate types of data into separate databases as well... other operations can rely on heavy caching, such as maintaining the list of dbs for each client, etc.

You CAN use a single database instance or file for everything, you can also use multiples to scale without falling strictly into a heavy vertical or horizontally scaleable database system. Especially if those db instances are distributed over a network channel to different physical servers on the back-end (as is with Turso).

I've worked on a lot of systems where I had advocated the use of separate DBs either on a oer-client or per-project basis... Even from a single management server, you can do a lot... from a small cluster operating against SQLite databases you can do more. With Turso's efforts to improve concurrency, it can go further still.

I'm not an employee, related to, or even an active customer right now... but I do understand the model and how it can work in a lot of use cases.

Comment by oofbey 1 day ago

If each client has its own database, does that mean you're automating the infra to turn on a new instance for each database, and then routing requests appropriately? Not too hard with k8, I suppose. Or if you add new clients infrequently enough it's a manual task. But you wouldn't do this for each user - it assumes you have some higher level of organization (client/tenant/org/etc).

Sounds like these are different ways of manually sharding the database?