| We have moved to FDB for our messaging platform. We had several options: a) Rewrite SQL code. In our case we are using Node.JS and all SQL libraries are very very slow. Even replacing one with another is enormous work.
b) Rewrite to a new language. It was also an option since querying Postgres can take 1ms, but parsing response can easily take 100ms+. That trashed our event loop and causes awful latency.
c) Rewrite to high performance NoSQL database. We picked a last one. In context of a Node.js we were able to write really thin layer on top of FDB that works super-fast and in a way we needed. In my previous startup we eventually ditched all SQL from our codebase too since SQL databases is just too slow for low latency messaging apps. There are no simple way to shard data, there are always random locks around your database (which blocks connections). Locks are really hard to debug sometimes. How to scale single SQL server? All of this is doable, but in FDB it was basically free. We migrated to FDB and got almost x100 improvement in latency/performance. And unlike SQL-code that was very carefully crafted we can do nasty things. Like - "hey, let's just pull this key every 100ms and check for a new value" or "hey, let's do it on 10s of instances at the same time?". In this situations Postgres started to consume all available CPU. You can easily creep out SQL with a single instance of your app. We haven't managed this to do with FDB for 1/2 of the cost. We are often in situation when someone commit something with a bug and, for example, started to pull data every millisecond in N^2 streams where N is number of online users. In this situations we just can't see any impact at all on our platform. Just spikes in monitoring. FDB is wonderful thing - it allows you to forget about optimizing performance of your queries, forget about managing backups and replication. It just works! |
Ouch. Is that just large amounts of data? Are you guys using pg.native?