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

SQLite Is All You Need

dbpro.app

Post reply on HN
Print view View original

11–20 of 66 posts

Re: SQLite Is All You Need

#11

Post by teaearlgraycold »

petcat wrote: post #10

> 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 fop…

For 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.

Re: SQLite Is All You Need

#12

Post by adzm »

teaearlgraycold wrote: post #11
petcat wrote: post #10

> 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 fop…

For 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.

WAL mode allows concurrency with reads and writes fwiw

Re: SQLite Is All You Need

#13

Post by callamdelaney »

teaearlgraycold wrote: post #11
petcat wrote: post #10

> 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 fop…

For 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.

Yeah 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.

Re: SQLite Is All You Need

#14

Post by smarx007 »

teaearlgraycold wrote: post #11
petcat wrote: post #10

> 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 fop…

For 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.

https://lobste.rs/s/ko1ji1/lobste_rs_is_now_running_on_sqlit...

Re: SQLite Is All You Need

#16

Post by fsuts »

faangguyindia wrote: post #8

lobster.rs also started using sqlite, i've been using exclusively using sqlite for most of my projects. apps appear much faster because db is on the same server

How are lobster.rs handling writes? Are they queuing them synchronously?

Re: SQLite Is All You Need

#17

Post by chistev »

The SQLite documentation says that

"SQLite works great as the database engine for most low to medium traffic websites (which is to say, most websites). The amount of web traffic that SQLite can handle depends on how heavily the website uses its database. Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic.

The SQLite website (https://www.sqlite.org/) uses SQLite itself, of course, and as of this writing (2015) it handles about 400K to 500K HTTP requests per day, about 15-20% of which are dynamic pages touching the database. Dynamic content uses about 200 SQL statements per webpage. This setup runs on a single VM that shares a physical server with 23 others and yet still keeps the load average below 0.1 most of the time."

Re: SQLite Is All You Need

#18

Post by chii »

petcat wrote: post #10

> 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 fop…

> 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).

Re: SQLite Is All You Need

#19

Post by mikeocool »

I love SQLite, but my clients expect minimal data loss and downtime when one of my servers goes down.

How are people solving that issue with SQLite? Everytime I’ve investigated it, it seems like the state of the art is not very battle tested WAL shipping solutions.

If I’m setting something like that up, suddenly running Postgres with its battle tested replication starts to look not so much more complicated in comparison.

Re: SQLite Is All You Need

#20

Post by inigyou »

chii wrote: post #18
petcat wrote: post #10

> 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 fop…

> 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).

If 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.

Post reply on HN