[samatman]

For a website, the question should be why not use SQLite.

Given the various compelling and (by now, here, I hope) well-understood advantages, it should be the default choice. Certainly for a site expecting hits in the mid-hundreds, total. Maybe ten simultaneous connections the day of?

[NikolaNovak]

Interesting, I interpreted the question completely differently, i.e. why use database at all?

FWIW, I'm not in the web app world, so my wedding website was a single page HTML; not a single page app, let alone a content management system - I googled something like "Wedding page HTML template", then grabbed a HTML template from w3schools, opened it in notepad, and put my own words and IMG tags. It looked pretty, was "responsive" by default, took very little time to create, and worked solidly.

I'm sufficiently old school / ignorant / pragmatic / lazy / focused / something, to wonder why complicate a wedding page with anything else :-)

(I mean, I'm old and ignorant and simple enough that I keep misinterpreting what "static site generator" is :P )

[Scarbutt]

Interesting, I interpreted the question completely differently, i.e. why use database at all?

Maybe the wedding page has forms, needs to store data and author is most familiar with Java or maybe they are getting creative and are calling third party services for convenience, lots of reasons. A simpler solution could be nginx/cgi and a local file for the DB, or cloudfare workers(you can render HTML from them) and their key/value storage.

[peanut_worm]

Yeah that was what I meant but everyone else seems to be commenting except the person I was replying to lol. I am not attacking databases I am just wondering what they used it for on a wedding website.

[samatman]

"Because my website is just pages and doesn't need a database" is a perfectly good reason not to use SQLite, sure.

OP can reply why a database was useful for his wedding site, if he wants; I can think of some reasons why it might be.