1y ago

Consider SQLite

blog.wesleyac.com Consider SQLite

66 comments

From their "code of ethics"
First of all, love the Lord God with your whole heart, your whole soul, and your whole strength.
Deny oneself in order to follow Christ.
Fulfill not the desires of the flesh; hate your own will.
There are even more strange ones, but I hope you get the picture. Reason enough to use something else if possible.
- If you actually read the page, it's intended as a tongue-in-cheek box-checker.
  This document was originally called a "Code of Conduct" and was created for the purpose of filling in a box on "supplier registration" forms submitted to the SQLite developers by some clients.
  This document continues to be used for its original purpose - providing a reference to fill in the "code of conduct" box on supplier registration forms.
  
  @colonial @Sibbo I'm actually glad I did read the page itself - it's clearly satire, making fun of how "sacred" others seem to hold their codes of conduct/ethics. I'm glad I read through that - I see no problems with it or in using SQLite.
  
  https://www.theregister.com/2018/10/22/sqlite_code_of_conduct/
  They are serious about the religious stuff. And someone who kicks the concept of a code of conduct with their feet like this is surely not a person that is nice to be around.
- Thanks, everyone knows they have a weird coc. It obviously only applies to the maintainers/members of the project though and is more of a statement than something that is actually enforced. As a convinced atheist, I also find it pretty weird but see absolutely no reason at all to avoid sqlite because of that. What matters is: Code quality/correctness (which is absolutely superb when it comes to sqlite) and license, of course. Why would I care about the authors beliefs? They don't even directly benefit from me using their product.
  
  @wordsnumber @Sibbo that was one hell of an opening sentence to misread.
- Some background: https://www.theregister.com/2018/10/22/sqlitecodeofconduct/
- I would think that's satire of insanely long and irrelevant rules documents.
  
  In other words, the developers are saying: "We will treat you this way regardless of how you treat us."
  I dk I don't think you can fake a persecution complex like that.
- Holy crap. I've used this thing for years and never had a clue they're a bunch of fruitcakes.
- Reason enough to deluse something else if possible/del read the docs.
- @Sibbo @chokidar they seem cool to me

I don't know, SQLite it's something that makes sense in theory, but I think its easier for ops people to just use a proper database. If you need to move the database to a separate machine, limit permissions, etc. its just easier to do.
SQLite is great for local apps that need a structured way to store their data, but I'm not really comfortable using it for more than that.
- Use the tool for the job. It is simple advice, but it will make your life so much easier.
  
  I do use the tool for the job. I don't understand your point.
- Personally I never do permissions at the database layer anyway - it's always done at the application layer.
  I also never move the database to a separate server - that adds too much latency. If your database is local, and "hot" tables are cached in RAM, you can do several hundred thousand queries in a split second and having performance like that can drastically reduce complexity in your business logic (and therefore, drastically reduce bugs).
  
  Regardless, I don't see it as something that is the silver bullet that people make it out to be. Being able to introspect the production database, query it, and generally have a set of tools to properly manage your data as opposed to having everything in a file fully managed by your application is something useful for me that you lose with SQLite.

I've built and deployed specifically small applications using sqlite and yeah I agree with everything, but especially the migration pains. Any change becomes difficult and bringing another developer onto a project just slows it to a crawl when db changes are needed. If that can be resolved I could be convinced, but until them postgres4lyf

I use SQLite to power up lots of stuff I'm working on. It's lightweight, fast, simple and well-documented for small projects — like a Postgres but very local. Saves me from having to deal with containers "just to store data", let alone for moving stuff to other machine where I would also need the permissions to configure and run containers in the first place; whereas all you need to pass SQLite databases along is scp / rsync.

I love SQLite! My current project actually uses it to serve read-only web content - it's plenty fast, and it's really nice having everything baked into the executable. No need to juggle a separate database server.
Their docs are also superb - maybe I'm weird, but I like reading about stuff like atomic commit.

It's an interesting format for passing around information that's best structured as a database, thus useful for one of my current spare-time projects.

it uses a single file on disk as a backing store
While this is the norm, you can have one database in multiple files.
Also, provides benchmarks on a file-based database whithout providing any details on the underlying filesystem.

That was a good read, thanks!

In a world of containers and stateless applications, fuck SQLite.
- You can always use sqlite cloud
  /s?
- ... you know you can put SQLite in a container right? It doesn't even need to be persisted to disk - it can just live in RAM.
  
  If you don't care about persistence, why are you even using a DB in the first place?
- Just learn how to configure your containers.
  
  Please teach me how to configure my containers so SQLite can scale horizontally.

66 comments