It works great and it's less work for me.
SOLUTION BUILDER SQLIGHT COLLECTOR PASSWORD
It's one less database to administer, one less user and password to create and manage, and the SQLite file is saved using my regular backup routine. I now use SQLite whenever I can for low traffic services, unless the app developers strongly advise something else.I'd say there's no reason to bother with a client/server database like PostgreSQL / MariaDB / MySQL if you can help it. > In fact, I’d argue there’s no networked use case in which SQLite is cheaper, easier to deploy, maintain or run than Postgres. And yes, in this case, you might as well use PostgreSQL indeed. The page does not suggest using WAL, it suggests using WAL, " but do all reads and writes from processes on the same machine that stores the database file", is you use a networked FS.
WAL / rollback is how SQLite works by default.
> (unless you use WAL or rollback, in which case why not just use Postgres?)Īgain. Using SQLite for a network service when the app runs on the same machine as the SQLite file is perfectly fine. Not if the application is accessed over the network. This page suggests PostgreSQL if accessing the SQLite file from the application would induce a network connection (because of a network filesystem). > The SQLite documentation literally says use Postgres and not it for networked use cases We need an open source, distributed and relational store that’s easy to maintain build this decade. There was a moment where nosql was booming for the scaling but it turned out people like relations. We then moved over to networked apps where RDBMS had its day. In the 2000s desktop apps were rampant and SQLite was more or less the standard. The SQLite documentation literally says use Postgres and not it for networked use cases (unless you use WAL or rollback, in which case why not just use Postgres?)Īs an aside, I think we need a new storage primitive. There should be some optimizations in mirroring network state to IndexedDB that could be queried via SQl(ite). In fact, I’d argue there’s no networked use case in which SQLite is cheaper, easier to deploy, maintain or run than Postgres.Īll that being said, absurdsql is great. SQLite is meant to be embedded (also works great with desktop apps and local-only web apps).
SOLUTION BUILDER SQLIGHT COLLECTOR FOR ANDROID
I like SQLite (use it for android apps), but there’s no reason to use it for apps over a network. Schema changes are still a point of friction as your data grows larger, however fairly stable heavy read scenarios, the simplicity of a SQLite setup is very nice to use.ĭon't get me wrong, Postgres is a great default, but for a growing number of use cases, SQLite can be an extremely portable, cheap and efficient setup. With added attention, hopefully SQLite will continue to improve with extensions like Spatialite and others. And now with sidecar setups like Litestream, backup and disaster recovery of data is also a lot simpler and again, cheaper. There are definitely trade offs with SQLite around low write performance (due to single writer limitation), and definitely not as feature filled as Postgres, but I think a lot of people underestimate the read performance and simplicity of a single host setup. With SQLite you can easily deploy to services like Hetzner Cloud and get 4vCPU + 8GM RAM for ~$15/month and use Litestream for backup. So with the same 'micro' specs for an application server, you are paying $16/month. $8/month of GCP gives you 0.6GB memory and a single shared vCPU (no SLA), and you still need an application server. A lot of projects will never need beyond the scale that a SQLite host can offer, and gain from the lower bills and simplicity of a single host.
0 kommentar(er)
