4 ms·

The idea that mvSQLite is based on (decoupled storage and compute) has been implemented for the other two most popular SQL databases. MySQL and PostgreSQL have

The idea that mvSQLite is based on (decoupled storage and compute) has been implemented for the other two most popular SQL databases. MySQL and PostgreSQL have Aurora and AlloyDB, and PostgreSQL additionally has Neon. This is something missing from the SQLite ecosystem (before mvSQLite). And SQLite has a unique advantage when implemented on top of decoupled storage and compute. Decoupled MySQL and PostgreSQL can't really linearly scale from zero in a serverless use case: you need to spin up a compute instance when you want to do queries. This isn't necessary with mvSQLite, because the embedded SQLite library can just connect directly to the multi-tenant storage engine (mvstore).

phamilton 4y ago
> This is something missing from the SQLite ecosystem (before mvSQLite) This is also something missing from self hosted, open source, SQL rdbms. As far as I'm aware, this is the closest thing to Aurora and AlloyDB that I can run myself. Also, by leveraging FoundationDBs ability to have multi-writer deployments, it gives us the potential to scale writes far beyond what Aurora and AlloyDB can handle. I'd love to see an extreme benchmark comparing a single 24xlarge Aurora writer vs a few dozen nodes in FoundationDB. The Aurora writer is likely more efficient per CPU but ultimately can't scale past 96 cpus.