Hacker News new | past | comments | ask | show | jobs | submit login

From experience, before you just spinkle big ass string literals throughout your Go code that communicate with Sqlite, just toss all of your persistence in a separate package if you can. I'm not saying some crazy abstraction, just put it some place common if you don't have a lot of advanced SQL needs, and put in the minor extra work serializing to and from structs. You'll be happy when you want to add query logging, find certain usages, need code reuse, and if you ever want to change your persistence approach.

Also, devs should be aware of some of the concurrency limitations of Sqlite. Devs need to essentially share a single connection across the app, and serialize the writes.

Also, side note, I've found one really neat use case for Sqlite over other DBs: simple disk encryption. I wrote a Go wrapper for one of the popular ones [0], but in general if you distribute your app in other ways you may want to offer your users encryption that you can't easily with other DBs. Sure you lose some performance, but sometimes it's worth it (again, less in the server case where you control it and/or can do fs-level encryption, but definitely in the distributed app case).

0 - https://github.com/cretz/go-sqleet




The author talks about using multiple readers and serializing all writes to a single connection fyi. This is how you get really stellar update/write performance out of sqlite. In my test I saw 3x insert per second compared to Postgres for example.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: