All those features sound simple to do by hand, so if it doesn’t exist already, you should make it.
Ask HN: Wouldn't it be cool to have a Supabase for SQLite?
11–20 of 29 posts
Re: Ask HN: Wouldn't it be cool to have a Supabase for SQLite?
#12It's an obvious question, but have you looked into Pocketbase? https://github.com/pocketbase/pocketbase
that's pretty cool! Would be great to have it for TS to configure my own backend
You can use a third party NPM module to introspect the DB and write out types for you. Can’t remember what it’s called off the top of my head, but maybe “pocketbase-type gen” or something like that.
Re: Ask HN: Wouldn't it be cool to have a Supabase for SQLite?
#13Cloudflare D1 maybe?
https://developers.cloudflare.com/d1/
Re: Ask HN: Wouldn't it be cool to have a Supabase for SQLite?
#14It's an obvious question, but have you looked into Pocketbase? https://github.com/pocketbase/pocketbase
Pocketbase is awesome. And, you can add to pb_hooks and customize the server (in golang or JS) and do whatever you want in addition to the already incredible feature set. And, it works with litestream, so you can automatically backup and restore.
Re: Ask HN: Wouldn't it be cool to have a Supabase for SQLite?
#15If I understand correctly, the SQLite library would be embedded in a sidecar processes that would run on the same machine as the app main process, instead of having the SQLite library embedded directly in the app main process? But then, what's the point of using SQLite? What makes SQLite reads and writes so fast is that it is running embedded in the app process. If you don't need that, and you want a client-server architecture, then you can simply run PostgreSQL or MySQL on the same machine, also as a sidecar process (or as a subprocess of the main process), and communicate using UNIX domain socket.
Re: Ask HN: Wouldn't it be cool to have a Supabase for SQLite?
#16SQLite reads and writes are already very fast, in particular because it's running in process.
The minute you put it behind a socket, you lose that benefit. Also you would have to implement an efficient wire protocol.
I just don't see the added value here.
Re: Ask HN: Wouldn't it be cool to have a Supabase for SQLite?
#17You can do all of this with Postgres.
except for the single-file database
Re: Ask HN: Wouldn't it be cool to have a Supabase for SQLite?
#18Not directly an answer, but similar what if thinking got me wondering: wouldn't it be cool to be able to use postgres much like how you use sqlite with python? I implemented this idea as a pip-installable python package, https://github.com/orm011/pgserver, and your feedback would be great :) I use it for my projects.
Re: Ask HN: Wouldn't it be cool to have a Supabase for SQLite?
#19Not directly an answer, but similar what if thinking got me wondering: wouldn't it be cool to be able to use postgres much like how you use sqlite with python? I implemented this idea as a pip-installable python package, https://github.com/orm011/pgserver , and your feedback would be great :) I use it for my projects.
neat project! how have you found resource usage and startup time compares with SQLite?
Re: Ask HN: Wouldn't it be cool to have a Supabase for SQLite?
#20Not directly an answer, but similar what if thinking got me wondering: wouldn't it be cool to be able to use postgres much like how you use sqlite with python? I implemented this idea as a pip-installable python package, https://github.com/orm011/pgserver , and your feedback would be great :) I use it for my projects.
neat project! how have you found resource usage and startup time compares with SQLite?
I have not compared it.
Have you had issues in this front?
If you are asking in human terms, its instantaneous to start, it simply creates a few files etc and starts a process. If you were using Sqlite, there is no extra associated process. But the processes are simply waiting for your input, so normally this is not really extra work.
In benchmark terms, the way I'm using it startup time is not a huge issue, instead being able to use postgres is helpful (has extensions and you know you can eventually move to a hosted postgres if you want)
If startup really matters, the startup can be amortized (if multiple processes want to access the same file, they get a handle to the same already started process, so only the first one would have waited for startup).
In terms of ongoing resource consumption, I can easily have a bunch of separate servers running for different files (it depends on your workload how much work will happen behind the scenes.) I'm not sure how much extra work postgres needs to do vs sqlite beyond what is kind of inherent for a workload (eg index creation, saving a bunch of data etc).