Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Wouldn't it be cool to have a Supabase for SQLite?

news.ycombinator.com

Post reply on HN
Print view View original

21–29 of 29 posts

Re: Ask HN: Wouldn't it be cool to have a Supabase for SQLite?

#21

Post by iFire »

I've been keeping a fork of MVSqlite (sqlite on foundationdb) maintained.

What is Mvsqlite? According to the author it's a distributed, MVCC SQLite that runs on top of FoundationDB.

https://github.com/V-Sekai/mvsqlite

Made an Elixir client, a Godot Engine client and CLI.

Supabase on Mvsqlite would be great! I am still puzzling over Mvsqlite's write performance, but its read performance makes sense to me.

# ycsb (workloadf, 10000, --wire-zstd)

Run finished, takes 1m18.086881433s

READ - Takes(s): 78.1, Count: 99957, OPS: 1280.3, Avg(us): 27061, Min(us): 1409, Max(us): 98751, 99th(us): 59391, 99.9th(us): 81791, 99.99th(us): 94591

READ_MODIFY_WRITE - Takes(s): 78.0, Count: 50061, OPS: 641.6, Avg(us): 69636, Min(us): 13320, Max(us): 205823, 99th(us): 121215, 99.9th(us): 189823, 99.99th(us): 203007

UPDATE - Takes(s): 78.0, Count: 50095, OPS: 642.0, Avg(us): 42630, Min(us): 7792, Max(us): 200319, 99th(us): 81535, 99.9th(us): 175487, 99.99th(us): 195199

From the github actions tests the original author wrote.

Re: Ask HN: Wouldn't it be cool to have a Supabase for SQLite?

#23

Post by theage »

for dev there is already pg-lite server (postgres as nodejs/wasm) you can spin up, it's self-contained single-folder db to disk, 100MB RAM thingy. Highly experimental. Not sure if supabase codebase is setup for debugging the way you suggest.

https://github.com/kamilogorek/pglite-server

Re: Ask HN: Wouldn't it be cool to have a Supabase for SQLite?

#24

Post by DevNinjaS »

Hey thenorthbay,

I gotta say, your idea of a Supabase-like system for SQLite got me thinking. It's an interesting concept. SQLite running next to your server could certainly speed things up, but don't forget about potential issues with concurrent writes. SQLite might not be as graceful as other databases in handling those.

The dev-prod synchronization you mentioned is a neat idea. Just remember to keep things secure and don't expose sensitive data. Also, think about the size of your production database. If it's too big, this might not be the best way to go.

Having an interface to access, view, and modify data straight from the production DB would be super useful. Depending on how complex this gets, you could either make it part of the application server or set up a separate server.

Auto-backup to a bucket is definitely a thumbs up from me. Tools like Litestream can be a lifesaver here.

Have you heard of Datasette? It's an open-source tool that lets you explore and publish data from SQLite databases. It could be a good starting point for what you're trying to build.

Your idea sounds like it could really shake things up. Keep us posted on how it goes. Good luck!

Re: Ask HN: Wouldn't it be cool to have a Supabase for SQLite?

#26

Post by datascienced »

Leaderless, eventually consistent DB, with DB running on same servers as app.

Could be good, you need to rethink all the distributed DB stuff.

Does a node deal with certain subset (e.g. certain customers) so you use customerid as a partition key.

CRDTs?

Once a node fills up to say x% capacity do you split that out (using consistent hashing to minimize effect of such spits).

You probably end up reinventing one of the distributed DBs once you make it production ready.

I think it is a lot of work unless you have simplifying requirements e.g. just give each customer a seperate VM and then use a mounted cloud storage to scale up space to some max like 10Tb then maybe cap it there. Write your db log to s3 glacier for a backup.

Second replica for failover.

Re: Ask HN: Wouldn't it be cool to have a Supabase for SQLite?

#28

Post by exodust »

DevNinjaS wrote: post #24

Hey thenorthbay, I gotta say, your idea of a Supabase-like system for SQLite got me thinking. It's an interesting concept. SQLite running next to your server could certainly speed things up, but don't forget about potential issues with concurrent writes. SQLite might not be as graceful as other databases in handling those. The dev-prod synchronization you mentioned is a neat idea. Just remember to keep things secure…

This reads like an AI-generated comment. DevNinjaS, can you confirm?
Post reply on HN