PostgreSQL has been speculated to get "it'll be all better RSN" failover for as long as I've been using it (around 8.4 IIRC). ;-)
But yeah, what made FoundationDB's SQL-Layer exciting (for me) was:
- For small clusters it was free.
- Automatic HA
- Operationally Inexpensive (talking admin time/effort/training; far cheaper than PostgreSQL)
- Horizontal Scalability
The things that didn't matter for the 99%:
- It wasn't very fast.
I don't have "big data" problems (I could invent some). Most small shops (I suspect) don't.
The problem I do have is 3AM pagers, availability, wearing too many hats, putting dozens of hours into learning and experimentation to get PostgreSQL to use the hardware it's put on effectively, coming up with complex CARP+REPLICATION+FAILOVER plans, ZFS snapshotting because PostgreSQL still can't match the backup/restore process any commercial database had nailed down two decades ago, backing up the snapshots, figuring out how to partition clients into different table-spaces, blah blah blah.
You sacrifice some single-client performance with FoundationDB, but you solve almost every other problem you've got. And you now have the option of deploying a couple extra nodes to exceed your previously fairly intractable TPS milestones.
It's so easy in fact, you can now autoscale your database with your application servers.
And for your 80% of smaller clients it's absolutely free.
Your description of what matters to many customers doesn't get enough appreciation. Its faster too often trumps it lets me sleep at night in the battle for attention.
But yeah, what made FoundationDB's SQL-Layer exciting (for me) was:
- For small clusters it was free. - Automatic HA - Operationally Inexpensive (talking admin time/effort/training; far cheaper than PostgreSQL) - Horizontal Scalability
The things that didn't matter for the 99%:
- It wasn't very fast.
I don't have "big data" problems (I could invent some). Most small shops (I suspect) don't.
The problem I do have is 3AM pagers, availability, wearing too many hats, putting dozens of hours into learning and experimentation to get PostgreSQL to use the hardware it's put on effectively, coming up with complex CARP+REPLICATION+FAILOVER plans, ZFS snapshotting because PostgreSQL still can't match the backup/restore process any commercial database had nailed down two decades ago, backing up the snapshots, figuring out how to partition clients into different table-spaces, blah blah blah.
You sacrifice some single-client performance with FoundationDB, but you solve almost every other problem you've got. And you now have the option of deploying a couple extra nodes to exceed your previously fairly intractable TPS milestones.
It's so easy in fact, you can now autoscale your database with your application servers.
And for your 80% of smaller clients it's absolutely free.
Such a bummer. :-(