22 ms·
> the Postgres container you spun up out of habit was never needed These posts need to stop comparing their contrived use-cases for SQLite to Postgres. Sure,
by petcat 3mo ago
> the Postgres container you spun up out of habit was never needed
These posts need to stop comparing their contrived use-cases for SQLite to Postgres. Sure, SQLite is all you need if it really is all you need. But Postgres does so much more than just act as a data dump with an SQL engine on top.
Dr. Hipp himself even said that SQLite does not, and will never, compete with the likes of Postgres. It competes with fopen.
- teaearlgraycold 3mo agoFor example you cannot have concurrent access. As soon as you need a worker process and a web process SQLite is out. Or if you are trying to use it as a vector db all of those vector searches will block a node event loop.
- adzm 3mo agoWAL mode allows concurrency with reads and writes fwiw
- callamdelaney 3mo agoYeah it blocks for the 0.001ms it takes for 99.99% of queries to come back. Or you can enable WAL and allow readers to read at the same time as somebody is writing.
- smarx007 3mo agohttps://lobste.rs/s/ko1ji1/lobste_rs_is_now_running_on_sqlite https://lobste.rs/s/ko1ji1/lobste_rs_is_now_running_on_sqlit...
- chistev 3mo agoThat site is hard on my eyes
- Cthulhu_ 3mo agoArticle mentions WAL and how this sentiment is about 16 years out of date. But also, you can duplicate databases for out-of-order processes. But also also, if you have higher concurrency requirements - e.g. multiple servers, one database - or a more write-heavy use case, sqlite is no longer the right choice.
- chii 3mo ago> SQLite is all you need if it really is all you need. most use cases are really capable of being satisfied by sqlite, but the "architect" imagines they need more (or is preparing for the potential).
- inigyou 3mo agoIf you could conceivably use multiple processes at once to access the database, and not just as an edge case, you need something more than sqlite. Sqlite does support multi-process access correctly, but the performance is abysmal as it locks the entire file for any write transaction. Client/server databases have much smarter concurrency.
- masklinn 3mo agoIt’s perfectly fine if your write throughput is low, especially in wal mode. Multiprocess does not actually change much if anything, even in multithreaded mode you want every thread to have its own connection and to have a good handle on who is writing when.
- inigyou 3mo agoRegardless, it's a sign sqlite is not right for you. You should start with postgres if you aren't sure your application will always be good with sqlite. It'll save you a migration, and doesn't really cost anything to start your project with postgres instead of sqlite.
- mahcha 3mo agoThere is an interesting pattern SyncLite (https://github.com/syncliteio/SyncLite https://github.com/syncliteio/SyncLite) attempts to solve to bring the best of both SQLite and Postgres with one or more SQLite databases directly serving the application while SyncLite replicating/consolidating data from all those SQLite databases into a centralized PostgreSQL database..
- 3mo ago
- TZubiri 3mo agoand for that matter, fopen is all you need, you do not need sqlite
- haspok 3mo ago> It competes with fopen. No, it actually competes with Excel. At least in the finance world, there are still a million small processes driven by an Excel spreadsheet put together in an afternoon by an intern 20 years ago. If it is a really business critical process, then the input is usually a csv file, read by an Excel macro. Because Excel is user friendly, and "is good enough". Mostly...