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

61–66 of 66 posts

Re: SQLite Is All You Need

#61

Post by petcat »

masklinn wrote: post #59
petcat wrote: post #48

Earlier quoted context omitted.

Well for one we should probably validate that the number is smaller than the total life of the physical universe. SQLite will gladly store a u64::MAX as a "unix timestamp" despite it being about 300x larger than the number of seconds that the universe and everything in it has existed. Try reading that back in any application date/time code and your app probably crashes immediately.

> SQLite will gladly store a u64::MAX as a "unix timestamp" SQLite does not support unsigned integers. > Try reading that back in any application date/time code and your app probably crashes immediately. Postgres will happily ingest and produce dates in the 280th millenium, which will also crash your application if its datetime type can’t handle that shrug . You can add a check constraint that your field passes throu…

> SQLite does not support unsigned integers.

omg you're right. Another example of SQLite's type-flimsyness.

> You can add a check constraint

So now we're just layering on our own brittle validation and runtime checks to make up for sqlite's woeful deficiency supporting even basic domain data types.

Re: SQLite Is All You Need

#63

Post by JSR_FDED »

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…

Lots of interesting stuff in your post, thank you for sharing it. But please just write in your own voice - LLMs just make it worse.

Re: SQLite Is All You Need

#64

Post by masklinn »

petcat wrote: post #61
masklinn wrote: post #59

Earlier quoted context omitted.

> SQLite will gladly store a u64::MAX as a "unix timestamp" SQLite does not support unsigned integers. > Try reading that back in any application date/time code and your app probably crashes immediately. Postgres will happily ingest and produce dates in the 280th millenium, which will also crash your application if its datetime type can’t handle that shrug . You can add a check constraint that your field passes throu…

> SQLite does not support unsigned integers. omg you're right. Another example of SQLite's type-flimsyness. > You can add a check constraint So now we're just layering on our own brittle validation and runtime checks to make up for sqlite's woeful deficiency supporting even basic domain data types.

> omg you're right. Another example of SQLite's type-flimsyness.

You're just firing on all the bullshit cylinders in your little motorised gish gallop aren't you?

The only RDBMS in widespread use which supports unsigned integers is mysql. Not postgres, not oracle, not sql server, not db2, not snowflake, not databricks.

> So now we're just layering on our own brittle validation and runtime checks to make up for sqlite's woeful deficiency supporting even basic domain data types.

Ah yes, the "brittle validation" of actually validating the thing you purported to care about two comments ago. Amazing.

Re: SQLite Is All You Need

#65

Post by callamdelaney »

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

Earlier quoted context omitted.

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

So you don't have a redundant server until $1marr? That means you also don't apply updates to the server/kernel that require a reboot until then? Or you accept the downtime? And what happens if it doesn't boot properly?

None of that is an issue depending on what your software actually does. Now sure if you're doing something like logging, or you're cloudflare, or meta or some shit then yeah it's not going to cut it.

Generally I target enterprise b2b customers, they use the application from 9-5 generally. Weekly scheduled downtime is not the end of the world.

If it doesn't boot properly, which has never happened, I build a new server - takes 10 minutes max. Litestream keeps database relatively fresh, so it gets pulled on boot. Floating IP points at new server. We do this in dev regularly, the only difference in prod is a few variables.

Even if your target is higher uptime or bigger scale, you can go far further than you think on sqlite - it's multitudes of magnitude quicker than postgres for most general use cases.

Most software projects go nowhere. YAGNI. Build something valuable and people will put up with bullshit for a while.

Re: SQLite Is All You Need

#66

Post by danosull »

simonw wrote: post #45
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

"No version upgrades, no connection limits, no pooler, no failover drill, no separate thing to monitor, no separate thing to pay for" Inspired me to finally build (well, vibe code) a cliché detector https://tools.simonwillison.net/llm-cliche-highlighter

It's fun that this doesn't actually flag anything on my recent blog post about clichés and LLMs, which deliberately lists cliches. I think because I'm focusing on words and this is looks for phrase patterns?

https://blog.osull.com/2026/07/06/cliches-in-the-age-of-the-...

Post reply on HN