What exactly is the benefit of using sqlite over mysql in this case?
Is the 10-15 minutes you might save looking up a quick setup tutorial for the system provided packages really worth the later problems? Postgres is slightly more complex (but pays for itself with additional capabilities), so I can see avoiding that unless your are already familiar with it.
As for PHP, at this point it's not really any easier or harder to get up initially then Python, Ruby or Perl, so it really comes down to personal experience. Whichever one you know best, use it. Whichever framework you know best that has some solutions for what you want to do, use it. That will be quickest.
I don't run a MySQL server on my personal computer. I don't want to run one. If I want to start writing code right away to flesh out an idea, SQLite is the tool I can use, it enables me to develop locally with no SSH/FTP overhead or setting up a VM. It lets me start writing code instantly. And it's performant enough for most any MVP, and the SQL dialect is pretty standard so you can upgrade to Postgres or SQLAnywhere or whatever you please when the time comes.
1. You don't necessarily want to develop in the same environment you deploy to.
2. You don't want to install some things on your development machine.
Together, those are dictating some development directions for you. That's fine. Those are perfectly valid choices. But I think it's easily summed up in your case as "You use sqlite because it fits well with your current development pipeline."
On the flip side, I do development on remote servers using vim. For me, sqlite provides little-to-no additional benefits, since MySQL or Postgres are a package install away (if not already installed), and that's a small price to pay for their additional benefits (for example, a much richer set of data types). At the same time, this type of development pipeline makes certain types of development harder (there's lots of tools for vim/emacs, but some things graphical IDEs provide are harder to achieve).
There is a middle ground, which is emulating the target environment through a VM on the development machine. It should provide the best of both worlds, for a cost of a little most complexity. I've never really gone for that, as I'm happy with the remote dev setup I have, and it's easier not to have to devote local resources to that for me. It's a popular choice as I understand it though.
I think you should be able to understand that sqlite's "the database is a file, ONE file" is superior to getting a fully configured and setup mysql up and running in speed, ease, and simplicity. Of course, it presents limits in terms of scalability (however because it is linked into the application rather than using TCP, if you want to do 400 sql queries per page view sqlite will be MUCH faster than mysql or postgres is going to be)
And in fact Sqlite is linked with the application, so it presents a development environment much more consistent with production (if that's also using sqlite of course) than any mysql or postgres ever will.
I usually go for Postgres, but I suppose one advantage is that backing up involves the filesystem rather than figuring out how to do a db dump. Not entirely sure if it's that simple though.
Is the 10-15 minutes you might save looking up a quick setup tutorial for the system provided packages really worth the later problems? Postgres is slightly more complex (but pays for itself with additional capabilities), so I can see avoiding that unless your are already familiar with it.
As for PHP, at this point it's not really any easier or harder to get up initially then Python, Ruby or Perl, so it really comes down to personal experience. Whichever one you know best, use it. Whichever framework you know best that has some solutions for what you want to do, use it. That will be quickest.