Like others have commented, those numbers seem to be too high for writes.
On the other hand, the Fauna numbers don't seem that impressive to me. On a mid-2011 Macbook Air, I get 2600 transactions per second (read-committed) in PostgreSQL 9.6.
Setup is as follows:
CREATE TABLE IF NOT EXISTS foo(a TEXT, b TEXT, c TEXT, d TEXT);
CREATE INDEX IF NOT EXISTS idx_foo_a ON foo(a);
CREATE INDEX IF NOT EXISTS idx_foo_b ON foo(b);
CREATE INDEX IF NOT EXISTS idx_foo_c ON foo(c);
CREATE INDEX IF NOT EXISTS idx_foo_d ON foo(d);
-- prepared statement, the inserted strings are 4 chars wide
INSERT INTO foo(a, b, c, d)
VALUES
($1, $2, $3, $4),
($5, $6, $7, $8),
($9, $10, $11, $12),
($13, $14, $15, $16);
These numbers are for one thread doing the writing.
Well, you're missing that in Faunas case the writes are durably stored on N machines. I.e. their system provides fault tolerance in case a machine fails. You can't really do the same thing with postgres (without trading off full ACID compliance).
True. Thanks for pointing that out. I think they probably should be putting the emphasis in their marketing on the fault tolerance i.s.o. the performance.
Quorum commit is not the same as distributed strict serialization because replicas can desynchronize.
Additionally you have the bottleneck of a single master. Will it be possible to do a quorum read as well, and will every transaction on the master be doing it? Then you are starting to get closer, although many anomalies are still possible.
On the other hand, the Fauna numbers don't seem that impressive to me. On a mid-2011 Macbook Air, I get 2600 transactions per second (read-committed) in PostgreSQL 9.6. Setup is as follows:
These numbers are for one thread doing the writing.Am I missing something?