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

Soul: A SQLite REST and Realtime Server

thevahidal.github.io

Post reply on HN
Print view View original

11–20 of 53 posts

Re: Soul: A SQLite REST and Realtime Server

#11

Post by galaxyLogic »

ginko wrote: post #2

I thought the whole point of sqlite is that you don't have to deal with the cruft and overhead of having to send queries over a network connection. Why tack that back on?

>I thought the whole point of SqLite is that you don't have to deal with the cruft and overhead of having to send queries over a network connection. Why tack that back on?

An interesting application could be a web-application whose ONLY server is the SqLite -server. The state of the application would be stored into the SqLite database, not into "local storage" etc. Using a relational database is a great improvement in flexibility over using the key-value store of Local Storage.

Could this work? I guess we would need to load one web-page into the browser first to load some HTML and scripts and then that page could use fetch() to get everything else from the SqLite -server.

Re: Soul: A SQLite REST and Realtime Server

#12

Post by chongli »

galaxyLogic wrote: post #11
ginko wrote: post #2

I thought the whole point of sqlite is that you don't have to deal with the cruft and overhead of having to send queries over a network connection. Why tack that back on?

>I thought the whole point of SqLite is that you don't have to deal with the cruft and overhead of having to send queries over a network connection. Why tack that back on? An interesting application could be a web-application whose ONLY server is the SqLite -server. The state of the application would be stored into the SqLite database, not into "local storage" etc. Using a relational database is a great improvement i…

What’s the security model for this? Seems like you’d end up with users able to run arbitrary queries against the database.

Re: Soul: A SQLite REST and Realtime Server

#13

Post by johnny22 »

galaxyLogic wrote: post #11
ginko wrote: post #2

I thought the whole point of sqlite is that you don't have to deal with the cruft and overhead of having to send queries over a network connection. Why tack that back on?

>I thought the whole point of SqLite is that you don't have to deal with the cruft and overhead of having to send queries over a network connection. Why tack that back on? An interesting application could be a web-application whose ONLY server is the SqLite -server. The state of the application would be stored into the SqLite database, not into "local storage" etc. Using a relational database is a great improvement i…

There's also the wasm build of sqlite that you could just run directly if it's really necessary. Of course there might be performance differences

Re: Soul: A SQLite REST and Realtime Server

#14

Post by johnny22 »

_heimdall wrote: post #4
ginko wrote: post #2

I thought the whole point of sqlite is that you don't have to deal with the cruft and overhead of having to send queries over a network connection. Why tack that back on?

That's a great question. This pattern is actually getting popular today with services like Turso and Cloudflare D1 (technically only SQLite compliant ). There are a few reasons I can see reaching for SQLite behind an API rather than something like Postgres. Portability can be a big benefit and I would expect you don't need to deal with connection pooling. If I had a service running on a single box and didn't mind set…

I've found postgres via docker to be fine for dev and testing, but there are various epheremal postgres scripts, plus this could be promising for node stuff https://github.com/electric-sql/pglite if it works out. I'd imagine if this does work out we'll see the same kind of builds for other runtimes as well (like python)

Re: Soul: A SQLite REST and Realtime Server

#15

Post by [deleted] »

_heimdall wrote: post #4
ginko wrote: post #2

I thought the whole point of sqlite is that you don't have to deal with the cruft and overhead of having to send queries over a network connection. Why tack that back on?

That's a great question. This pattern is actually getting popular today with services like Turso and Cloudflare D1 (technically only SQLite compliant ). There are a few reasons I can see reaching for SQLite behind an API rather than something like Postgres. Portability can be a big benefit and I would expect you don't need to deal with connection pooling. If I had a service running on a single box and didn't mind set…

[deleted]

Re: Soul: A SQLite REST and Realtime Server

#17

Post by geenat »

No benchmark = no download.

Plenty of these SQLite web front ends exist, including more enticing single static binaries in go, and they are always far too slow to use in anything but toy projects.

Should be standard to bench against a standard SQLite integration (on modern cpu with nvme).

Even PocketBase, for as nice as the UI is, an order of magnitude slower than SQLite directly.

Here's some rough numbers I've found using SELECT * FROM user LIMIT 1; per second ( 1x / 10x / 100x )

SQLite

68,000 / 50,000 / 4,000

SQLite WAL2 (3x Database files)

67,000 / 52,000 / 8,000

Pocketbase (CURL)

15,000 / 2,300 / 234

Pocketbase (Direct)

62,000 / 29,000 / 3,900

ws4sqlite (CURL)

20,000 / 2,600 / 255

Re: Soul: A SQLite REST and Realtime Server

#18

Post by jddj »

geenat wrote: post #17

No benchmark = no download. Plenty of these SQLite web front ends exist, including more enticing single static binaries in go, and they are always far too slow to use in anything but toy projects. Should be standard to bench against a standard SQLite integration (on modern cpu with nvme). Even PocketBase, for as nice as the UI is, an order of magnitude slower than SQLite directly. Here's some rough numbers I've found…

Curious to see how much it is a factor, did you run the same with/without cgo?

Re: Soul: A SQLite REST and Realtime Server

#19

Post by geenat »

geenat wrote: post #17

No benchmark = no download. Plenty of these SQLite web front ends exist, including more enticing single static binaries in go, and they are always far too slow to use in anything but toy projects. Should be standard to bench against a standard SQLite integration (on modern cpu with nvme). Even PocketBase, for as nice as the UI is, an order of magnitude slower than SQLite directly. Here's some rough numbers I've found…

Btw ws4sqlite rewrite in rust that's allegedly faster: https://github.com/proofrock/sqliterg
Post reply on HN