During the afformentioned "Sproc Hell", we were putting application logic in the database. Of course, this made perfect sense: it was secure because of bound params and strict typing, it was fast because it avoided several trips to the database for multi query operations and even for single query statements, query plans were precomputed and cached by the DB. You were also able to tweak application logic without deploying code, which was likely a clumsy process involving more than one team and various manual steps. This is all bollocks, as we've learned many scars and gray hairs later.
Now, the proposal here is entirely different. While yes, you are creating a function in your database, you are doing it to access data in a JSON structure, per the OP. Because in Postgres you can create an index on the result of any expression, including a function, you can now create indexes on functions that parse and access data your JSON docs. And it's fast.
A little-known feature of Postgres' streaming replication is Synchronous Replication or 2-safe replication, available from version 9.1 onward. It allows you to specify that a given commit must be durable on a standby server prior to the server returning to the client.
You can turn this on cluster wide, or just for single transactions using session variables. In your example, you can specify that this update must be synchronously replicated, and as such the consequent request will show the user the updated data.
Postgres, as of 9.0, has binary log streaming replication built in, truth. Slony ad other logical replication solutions out there are quite hard to set up and come with their gotchas.
A rock solid one command (cli)/click (web) is a whole different story though, making it super easy to form more complex DB topologies and adapting them as your needs change.
JSON is much more powerful than hstore. Not only can it store different JSON data types (boolean, numbers) but also you can store documents with multiple levels deep, which is not possible on the hstore type.
Having said that, hstore is perfect when storing simple key/values. It's been battle tested and used for years and has some powerful and native indexing possibilities.
recent awesome discovery: you can use Inconsolata in your google docs to paste in code samples and whatnot, available from the Add Fonts item in the font picker.
> Also, I'd hope they will give a few months warning before flipping the switch completely, similar to how the hoptoad/airbrake switch went.
Funny you should say that, as I was involved in the hotpoad/airbrake transition and am now involved in the Heroku postgres one. The transition will be as smooth as we possibly can, no data will be lost, there will be plenty of time to move your data, and easy ways of doing so.
We are really excited about offering a development and free 9.1 postgres service, a huge step forward from the current 8.3 shared database service, and are looking forward to moving people over to the new instances.
I've had to develop a system like this before. We were a data centric, mostly SQL shop. The idea was that the BA, CEO, and other devs could all implement the system for different customers having slightly but sufficiently different business rules. This is how we did it. Thankfully it was rewritten and the few customers migrated to the new system before it had a chance to fall on its face.
Not sure what you mean by "safe" by default. Speed and performance have nothing to do with security, if that's what you mean.
The reason that the default Postgres configuration does not perform well is that Postgres runs on a number of operating systems, and it is not possible to make assumptions about the hardware and configuration of the host. For example, increasing configuration parameters like shared_buffers to any useful value will require you to tweak the OS'es kernel resources. The Postgres documentation does a great job at describing the process on a number of operating systems: