Yeah, there still a few places where Mongo is hardcoded (the prototype assumed Mongo everywhere, and we've gradually factored out these assumptions.) Most of these places have to do with the code that automatically starts mongod for you when you type 'meteor' to run your app in development mode. I think all of the database assumptions have been factored out of livedata, but we'll only know for sure once we have a second database packaged :)

And yes a second time: to package a sql database, you would ideally have a 'minisql', a client-side cache with a sql-compatible interface. It's not strictly necessary though. There's no reason a DDP[1] dataset couldn't use a different database API on the client and the server (say, sql on the server, mongo on the client), but if you did this and you wanted latency compensation, you'd have to write all of your methods twice, once against each API.

I am really excited about having sql support, but we tried really hard to defer anything that wasn't absolutely necessary for release :)

[1] DDP is the protocol that livedata speaks between the client and the server. In Meteor, the client and the server mostly keep themselves at arm's length. The client doesn't know that the server is made with Meteor, just that it speaks DDP, and vice versa.