hgimenez
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.
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.
Read more about it here: http://www.postgresql.org/docs/9.1/static/warm-standby.html#...
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.
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.
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.
-edit- "Make it Data-Driven" was the word.
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:
http://www.postgresql.org/docs/current/interactive/kernel-re...
2. Clean Code
3. Metaprogramming Ruby