A simple method may be to use the filesystem to store blog posts... but a database is much nicer, in my opinion.
If you were to write something which used the filesystem, it could use a folder in which files for each entry would be placed, and then use the file creation time to sort through... but performance might be a bit spotty. Alternatively, it could use a file xref-ing the files for each of the blog posts in the order which they should appear in the blog.
To improve writing performance, the file could be appended to (rather than prepended to) but then you'd have to read the file backwards. If you make each file xref record have the same length, then you could actually seek to the end of the file minus 25 * (the length of a record) to get the last 25 blog posts, then reverse the order.
For tagging, a similar method could be used: an xref file for each tag.
The blog could, however, be rather inflexible, as it would be difficult to remove blog entires (unless you just blank out the lines) and extremely difficult to insert and reorder. A possible solution would be to use linked lists of entries rather than single entries - in such a solution, the xref file would start with an identifier (perhaps a byte offset) of the last entry, which would point to the second to last, and so on and so forth. However, performance would then degrade as more and more posts are processed; if you have 1000 posts and someone looks at post 1000, the server will have to process through 999 first.
However, with a linked list, it would be trivial to create a page index which increments every time a post is added -- it would have records linking, for example, page 1 with the most recent post, page 2 with the 25th most recent post, and so on.
To allow URLs like myblog.com/2008/02/23/mypost, you could put the entry files into that same structure: a folder for 2008, a sub-folder for 02, and a sub-sub-folder for 23. The xref files for both tags and the entire blog would include the path (ie: 2008/02/23/blogpost.xml)
As for XML: large XML files can be unwieldy, which is why I recommend having many, separate files instead (whether you use XML or not).
