It's awesome that it has an ORM - but ever since I have started using Octopress, which is based on Jekyll, is the more I realize that we don't need a DB for 'just blogging'.
Plain, old, generated HTML works perfectly. Plus it is very easy to host.
If this is something you guys can implement, I would suggest looking at it.
Your hosting will be MUCH simpler, cheaper, more profitable (even though you say you are running a non-profit), general footprint will be smaller, and pages will load quicker.
That's just my $0.02.
I love what I see here, but I can't bring myself to going back to a db-powered blog from Octopress.
The day you guys implement something similar, you will have 1 more user though!
Either way....awesome execution and congrats on everything you guys have done. Love it so far.
I'm a half-way house person when it comes to CMSes and databases. I don't think raw content needs to go in the database, it can happily live on the file system (assuming a sane permissions regime) and you can delegate version management to git.
However I feel metadata and other structured data belongs in the database for the usual reason: to support unforeseen future queries. That is, to make plugins and widgets easier to develop and better performing (vs, for example, iterating over every post or every comment to perform some calculation).
> is the more I realize that we don't need a DB for 'just blogging'.
That works for you and me (we're using jekyll here) but not for people that want timed releases and an online editor. Comments will need some sort of database as well, so you'll have to rely on disqus or similar if you're running a static blog.
Because you need to write somewhere. Now, you can write to the filesystem if you really really want to, but only if there is a writable FS somewhere - so e.g. not on heroku - but in any case writing to the FS and then serving that document is a whole can of worms.
Actually what I want ideally is the admin interface to be a Node app. For drafts use sqlite. For scheduling use sqlite. When I hit publish I want it to generate static assets.
The blog itself I don't need to be served by the Node app, Apache or Nginx can do that fine.
Well, scheduling and static generation require a cron job that writes the static asset at the predefined time. It all gets complicated from here. You can write the static asset when it's first accessed for example and from there on serve the static file, but that requires a database/storage as well, so you're basically back to square one.
I'd not restrict myself to sqlite here either, but that's a minor nitpick.
Why does it require a database? Ghost has a Markdown editor and presumable stores posts in the database as markdown, just write the markdown to the file system instead of a database? I'm really not seeing any requirement for a database here.
Well, yes, you can write to the filesystem, that's why I'm saying "database/storage". See, heroku for example does not provide you with a writable filesystem and it's also easier to share a database over a couple of hosts than a filesystem. Also, if you want to schedule, you'll need to store the scheduling information somewhere. You can add it to the file itself, just as jekyll does but then you'll have to open all docs just to see if they need scheduling. Or you write a schedule-file, but by the time you're doing that you're effectively building a database. Why not go and use a "real" database adapter and use sqlite for all basic setups since basically, sqlite is a specially formatted file with a library providing useful abstractions on top.
I do suspect that Xylakant may be right elsewhere in this thread when she points out that it's not possible on Heroku, but I'm not sure.
Anyway, I would love to see Ghost use a pile of static Markdown files rather than a database for posts. Then, in a couple of years, when I want to use something else, I can take my pile of Markdown files and move along.
One problem I have with static HTML basic CMSes for non-personal publishers is that it can be a pain to migrate markup or templates if not rendered client-side.
If you've got thousands of pages, publishing a HTML change could require re-building of all static pages, which means it can be painful maintain once you get to a certain scale.
Are the posts stored in a db or are they generated HTML?