I'll own up to misunderstanding what you meant by dbquery. I had assumed you either just meant generally a database query, or something like the bit of LINQ library that also generates database queries, not to an existing executable. I also got off my butt and looked at the source for the tool other servers are running, and yep that's what's going on. My bad.
I wouldn't particularly worry about "the same format". As long as the data is parseable, somebody can always write a tool later to munge it to however it needs to look, especially if you open source whatever model code you'd be using to serialize it.
If the concern is just security, it'd be pretty trivial to throw up a lightweight API server using a framework in your language of choice, toss nginx in front of it, and limit requests to a specific incoming IP. Then your public-facing web server can just query that. The amount of code difference there is pretty negligible.
Actually using a replica would indeed generate more costs, but as I alluded to, I'd think you'd want a replica anyway. The alternative is all sorts of potential hilarity when you lose a drive on your db server and need to do a raid rebuild, or a rollback if the db eats its fingers. If the goal is stability, that should be pretty high on your list regardless of any export functionality.
If you do your interesting logic in an API layer separate from the website to alleviate your existing security concern, then all you are rewriting is the ability to read and display the output from that backend API call.
Burdensome is substantially better than nonexistent. Don't let perfect be the enemy of good enough. It's perfectly possible to throw together something that gives us safety now and then still build those other, cooler things later.
Besides, I bet if you create a crappy web interface, other people could throw together a tool to log in to your website, crawl through the character list, and scrape all of the characters without you having to build anything else.
Given how the centralized control model worked out for me in 2012, I tend to think that doing it "right" in this case is at least throwing together something simple so your players can manage their own character data before worrying about whether you can get more than 2000 players on a shard, but you are, of course, entitled to your own priorities.