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

41–50 of 53 posts

Re: Soul: A SQLite REST and Realtime Server

#41

Post by boffinAudio »

SQLite wrote: post #26
brigadier132 wrote: post #6

Earlier quoted context omitted.

Frankly, you thought wrong. The whole point of sqlite was to build a database for naval vessels. Aside from that, given it's open source, the "point" of it doesn't really matter anymore.

That is inaccurate. Ginko's statement is closer to truth. I was inspired to write SQLite while working with Informix on DDG-79 and I saw how useful an embedded database would be in some situations, compared to a client/server solution. So I went off and wrote SQLite on my own, while the development contract was on hiatus. There was never a request for SQLite or anything like it coming from the the navy (or more preci…

I've always wondered why sqlite came along, but adoption of msql (Matt Dillons' similar database stack) didn't catch on .. did you have any opportunity to review the existing database tools that were available at the time, and if so - what did you find?

I realize this question is a bit archaic so if there's not really any good answers, no worries - but as I was using Matt's msql in the 2000's in the same way that I now use sqlite, its something I often wonder whenever I set up a new sqlite.db ...

Re: Soul: A SQLite REST and Realtime Server

#43

Post by mattgreenrocks »

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…

I've had similar ideas recently.

If I have an SPA querying a moderately-sized static dataset, then something like this is appealing. I can stand up a container on Fly, store the SQLite DB on the volume, and serve directly from there without needing to worry about # of reads I involve (w/ something like Turso) or all the ops complexity of a real DB.

Re: Soul: A SQLite REST and Realtime Server

#44

Post by twsted »

hultner wrote: post #39
twsted wrote: post #22

Nice and a possible alternative to the very polished PocketBase. I'm working on something similar for PostgreSQL [0], with an API compatible with the excellent PostgREST [1]. I believe these tools can be of great utility in many projects and represent a generalization compared to the dedicated middleware that was popular a few years ago. Companies like Supabase are demonstrating this. [0] https://github.com/sted/smoo…

Cool! Are you doing this mostly as a fun exercise or do you have a plan to provide something postgrest does not in the future?

Glad you like it.

I have quite ambitious plans, even though it started as a hobby project. In addition to the already developed DDL functionality and multi-database management, the next main features will include:

* Admin UI

* Projects with templates and versioning

* Migrations and deployment

Re: Soul: A SQLite REST and Realtime Server

#45

Post by mst »

diggan wrote: post #35
brodo wrote: post #27

REST mentioned! https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...

You can either play along with words changing meaning, or you can die on this almost meaningless hills. Signed, with my crypto keys while hacking on side-projects. (I'm also in the camp of "I don't love it when words change literal meaning" but I've also realized there is literally nothing I can do to stop it)

HATEOS is a much cooler name anyway.

I mean,

"Let the restfulness flow through you" - lame

"Let the HATEOS flow through you" - now you're cooking with force

Re: Soul: A SQLite REST and Realtime Server

#46

Post by runlaszlorun »

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…

> No benchmark = no download.

Perhaps it's because I'm particularly snarky pre-morning coffee, but this doesn't come across as the welcoming attitude open source is supposed to be and comes across as downright entitled. Especially as the first thing to lead with. Maybe you didn't quite mean it that way?

I'm taking a wild guess to say that you don't have a screaming need to run 'SELECT * FROM user LIMIT 1;' tens of thousands of times per second on SQLite.

And if you did, I'm guessing you prob would be able to write your own API in front of it.

Am I wrong here?

Kudos to the authors of this tool. It looks great and I'd love to try it out on a recent project.

Re: Soul: A SQLite REST and Realtime Server

#48

Post by earthboundkid »

SQLite wrote: post #26
brigadier132 wrote: post #6

Earlier quoted context omitted.

Frankly, you thought wrong. The whole point of sqlite was to build a database for naval vessels. Aside from that, given it's open source, the "point" of it doesn't really matter anymore.

That is inaccurate. Ginko's statement is closer to truth. I was inspired to write SQLite while working with Informix on DDG-79 and I saw how useful an embedded database would be in some situations, compared to a client/server solution. So I went off and wrote SQLite on my own, while the development contract was on hiatus. There was never a request for SQLite or anything like it coming from the the navy (or more preci…

This was great, but you should have started the comment with "I'm D. Richard Hipp. You know nothing of my work."

Re: Soul: A SQLite REST and Realtime Server

#49

Post by pseudosavant »

lakomen wrote: post #42

Why SQLite? Why not provide a generic SQL interface? I never understood that. Why do people build this around SQLite?

Because then nobody has to stand up a database server separately. I have a toy project I want to move from MariaDB to SQLite just so I don’t have to maintain MariaDB just for this app. All I need is my JS runtime, Deno in this case.

Re: Soul: A SQLite REST and Realtime Server

#50

Post by geenat »

runlaszlorun wrote: post #46
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…

> No benchmark = no download. Perhaps it's because I'm particularly snarky pre-morning coffee, but this doesn't come across as the welcoming attitude open source is supposed to be and comes across as downright entitled. Especially as the first thing to lead with. Maybe you didn't quite mean it that way? I'm taking a wild guess to say that you don't have a screaming need to run 'SELECT * FROM user LIMIT 1;' tens of th…

Who really wants to build on top of something just to hit an immediate performance cliff?

How far you can vertically scale on one server before requiring a split or shard in your data is why it's a big deal.

A) App servers are easy to scale (stateless, add hardware).

B) Database servers are hard to scale (requires changing logic).

If you're immediately hitting B) you're probably screwed.

Post reply on HN