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

21–30 of 66 posts

Re: SQLite Is All You Need

#21

Post by petcat »

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

> the "architect" imagines they need more (or is preparing for the potential)

I guess I am one of those "architects" that imagines they need an actual date/time storage class instead of some stringly-typed text column that I hope will contain a parsable ISO8601 datetime string when I try to read it back.

Hipp said that it will never be added because it will bloat the size of the embedded object. Because that is what SQLite was designed for: single-user embedded databases. Like the address book on your phone.

Re: SQLite Is All You Need

#22

Post by inigyou »

callamdelaney wrote: post #15
0xblinq wrote: post #9

And what do you do when you need more than one server, for redundancy or scaling to more servers?

You move to postgres at that point. Though if you can't scale to $1marr with sqllite then ehhh

If you think this might happen then you should start with postgres - it'll save you a migration, and doesn't cost much.

Re: SQLite Is All You Need

#23

Post by Cthulhu_ »

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.

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

Re: SQLite Is All You Need

#24

Post by olmo23 »

Terretta wrote: post #7
audunw wrote: post #3

The tests and the numbers are interesting. The LLM writing style? Insufferable. It really wouldn’t have taken much effort to cut out the worst of the AI fluff, and maybe add some human touches

Sit with that for a second.* * is in the article

The honest mixed-workload number The honest version of scale Which means the honest answer to "should I use Bun for this" is: it depends

It's Claude.

Re: SQLite Is All You Need

#25

Post by bendangelo »

mikeocool wrote: post #19

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

litestream is good for this.

Re: SQLite Is All You Need

#26

Post by inigyou »

upmostly wrote: post #2

Author here. This started because I read Evan Hahn's STRICT tables post [1] last week and got curious how far "just use SQLite" actually holds up under real load, not toy benchmarks. So I built a small social app (Chirp: 50k users, 1M posts, ~2.5M follows) in one SQLite file, put it behind a plain Node server, and load tested it properly: real HTTP, real JSON serialization, autocannon hammering it over sockets. The w…

This comment was shadowbanned because an LLM wrote it, and HN uses an LLM detector.

Re: SQLite Is All You Need

#27

Post by Cthulhu_ »

chistev wrote: post #17

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

I remember this section for the 200 queries per page thing, which is a huge difference between sqlite and most databases. Most databases run in a separate process and use a network boundary to separate it from the server processes (socket connection or even http), which alone exacerbates the n+1 problem, and / or puts pressure on the amount of queries one should trigger per page view. SQLite doesn't care because it runs as part of the server process.

Re: SQLite Is All You Need

#28

Post by Cthulhu_ »

fsuts wrote: post #16
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?

https://sqlite.org/wal.html presumably.

Re: SQLite Is All You Need

#29

Post by TZubiri »

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…

and for that matter, fopen is all you need, you do not need sqlite

Re: SQLite Is All You Need

#30

Post by rmunn »

There's some bad advice in the article:

"Backups are a file copy. [...] you can back up a live SQLite database, under write load, without stopping anything."

This is straight out of section 1.2 of https://www.sqlite.org/howtocorrupt.html. Yes, you can do that, and sometimes you will end up with a valid, non-corrupt backup. But it's timing-dependent: lose the race and you'll end up backing up a partially written transaction, making the backup corrupt. They didn't end up losing that race when they wrote the article, but that doesn't mean it is safe 100% of the time.

The section later on about running "VACUUM INTO backup-$(date +%F).db" is 100% safe, though: SQLite guarantees that you'll get consistent state if you do that.

Post reply on HN