WTF with VCs investing into all this crap? There are very few scenarios were you would be better off with NoSQL solution and there are established players serving those niches already.
I'm tired of seeing this argument. What they are putting at risk is the faith of investors who trade in USD and the belief that the US economy is robust and healthy.
Creating $ out of thin air also creates inflation within the financial system, benefitting debtor institutions and hurting creditors. It also sets a precedent that the Fed will simply push the magic money button whenever something goes wrong, which affects market behavior.
The Fed pays a price every time it takes any action - you just have to think harder about what that price is.
If FED takes a position on their balance sheet that get's wiped out (very theoretical since cost of carry for FED is 0) This does very little to erode investor confidence compared to having full blown meltdown. In any case FED eventually increased it's balance sheet to almost 20% of GDP around 2012
so it might have being cheeper to bail out lehman brothers
There is thins annoying thing called security with such things as trust boundaries etc. So if you are creating a mildly secure web app the only permission your web apps db user has is to execute a subset of stored procedures and that is it.
I guess you better let everyone know that their web platform isn't secure unless they are using a SQL database with stored procedures. Which would make PSN, Steam, iCloud, Office365, Gmail, Facebook, Twitter all insecure right ?
Generally if you have exposed your db credentials it's because something has gone very wrong i.e. your entire host has been compromised in which case stored procedures aren't going to save you.
White it's not unique to you there would likely be many people here who are aware of the concept of trust boundaries and would appreciate this product :)
Yeah you're right and I can think of several cases, especially in legacy software, where this would be helpful. I just feel that this is one of those things that delegates responsibility to a lower level component due to a flaw in one above it, with the major benefit being that no code changes are required to implement the system, but coming with the cost of increased DB CPU and IO consumption.
It's relatively easy to adjust this setup to use synchronous replication. In fact, it's something that I expect we'll be offering to customers in the future. Most people we talk to aren't willing to sacrifice the write availability or performance synchronous replication requires. We mostly try to give them the tools to do it right, and then educate them on the tradeoffs.
Is it even possible to guarantee that you won't lose commits with postgresql replication? For many applications, consistency is more important than not losing any data ever. For the other kind of application, you'll need something else.
With postgresql synchronous replication, in order to lose writes that have been acknowledged to the postgresql client, you'd have to lose filesystem data on both the primary and the synchronous standby. (I believe the way postgresql uses the term "committed", you can lose data that's "committed", but not once postgresql has acknowledged it to the client.)
For many applications, consistency includes not losing acknowledged data. If I PUT data into an application and fetch it back and it's not there, that's not consistent.
> For many applications, consistency includes not losing acknowledged data. If I PUT data into an application and fetch it back and it's not there, that's not consistent.
Durability and consistency are two separate concepts.
