Maybe. I've used XML as a file format for all my recent projects. It's well supported in the .Net framework, I don't need any 3rd party assemblies. Using SQL to write out an object graph would involve more work.
Also XML makes me weep and I'll never willingly opt to use it if there's an alternative, but that's my own prejudice.
Once your XML file hits a certain size, minor updates incur a gigantic performance penalty because you have to write out the entire XML file every time.
Random writes in the middle of an XML file are impossible. For example, if you were to change an attribute so that it's one character longer, you still have to rewrite the remainder of the file in order to shift everything over by one character.
That's the main reason why SQLite is so popular for applications.
(I know that's from personal experience. I had to support an old version of an application that constantly wrote out XML while the new version that we hadn't shipped used SQLite. A customer that made heavy use of the old version basically hit the limits of XML but the version that used SQLite wasn't ready for them yet.)
But, I'm going to be honest here: We had some tables that only had a few rows, so I moved those to XML files. QE really liked it because it was easy to diagnose issues.
Now your application should continuously save without any manual steps.
If you're having to do things like updates over a large dataset, SQLITE can be nice because of the performance boosts from indexing.