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.<p>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.<p>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).<p>0 - <a href="https://github.com/cretz/go-sqleet" rel="nofollow">https://github.com/cretz/go-sqleet</a>