(Marco from Citus Data) It depends on the use-case, but PostgreSQL and Citus can be a sensible alternative to NoSQL. RDBMS and NoSQL are on the opposite ends

(Marco from Citus Data) It depends on the use-case, but PostgreSQL and Citus can be a sensible alternative to NoSQL. RDBMS and NoSQL are on the opposite ends of the scaling spectrum. RDMBS provide very rich functionality and put few restrictions on your data model, but require the data to be stored one big lump on a single machine. NoSQL databases provide minimal functionality and put severe restrictions on your data model (must be a key->value set), but can distribute the data across many machines. Citus sits somewhere in the middle. The ideal use-case for Citus is one in which your data is kind of lumpy/relational, but can still be distributed by a particular key. The most notable example is multi-tenancy [1]. If you're running a (B2B) SaaS application with many customers, your queries are usually specific to a particular tenant, which means you can probably add a tenant_id column to all your tables and distribute the tables by that column. Citus automatically co-locates [2] data to support joins between different tables on tenant_id. You can then use full SQL and ACID transactions as long as you're always filtering by one specific tenant, and a useful subset of SQL for parallel queries across all tenants (incl. inner/outer joins). Citus is far more capable than most databases in this area, partly because it can build on the querying features of PostgreSQL, rather than having to implement them from scratch. The main advantage of using Citus over PostgreSQL in this case is that you can scale out memory, CPU, and storage space to keep up with your read workload. In addition, it provides parallel aggregations through INSERT..SELECT and parallel indexing when performing a COPY, allowing you to keep up with bulk write workloads. The main drawback is that you cannot perform arbitrary SQL queries across all the data and some queries may require a different data model. The main advantage of using Citus over NoSQL in this case is that you can use arbitrary single-tenant SQL queries and indexes, which makes data modelling far simpler and thus cheaper. Being able to perform parallel cross-tenant analytical queries and parallel aggregation [3] also avoids the need for maintaining separate systems for analytics (again, cheaper). Bulk loading through COPY can provide extremely high write throughput at relatively low cost [4]. A drawback is that, to provide consistency, Citus has designated primary nodes for taking writes. If a primary goes down there will be ~1 minute of down-time for the keys stored on that primary until the secondary takes over (similar to e.g. Kafka). However, this is not a huge concern for most applications, especially considering that PostgreSQL is very stable software so crashes are usually only hardware related. In a pure key-value storage use-case, the extra functionality provided by Citus is not as beneficial as it is in the multi-tenant use-case, though features like JSONB, GIN indexes, SQL functions and ACID transactions can still be invaluable. In terms of short request throughput, regular Citus is comparable to a single PostgreSQL node in being able to sustain around ~50k writes/sec, which is less than typical NoSQL databases. However, if you need more than 50k/s writes, then Citus MX will be able to scale out your write workload horizontally [5]. For key-value use-cases, I would say Citus (MX) is competitive with NoSQL databases, but not specifically better or worse, just making different trade-offs. The big advantage is mainly that, if one day you decide you also need analytics, or a new query, or a new filter, or a new conversion, then you don't need to deploy a new system and probably won't have to remodel your data. [1] https://www.citusdata.com/blog/2016/08/10/sharding-for-a-multi-tenant-app-with-postgres/ https://www.citusdata.com/blog/2016/08/10/sharding-for-a-mul... [2] https://www.citusdata.com/blog/2016/12/22/scaling_out_sql_with-colocation/ https://www.citusdata.com/blog/2016/12/22/scaling_out_sql_wi... [3] https://www.citusdata.com/blog/2016/11/29/event-aggregation-at-scale-with-postgresql/ https://www.citusdata.com/blog/2016/11/29/event-aggregation-... [4] https://www.citusdata.com/blog/2016/06/15/copy-postgresql-distributed-tables/ https://www.citusdata.com/blog/2016/06/15/copy-postgresql-di... [5] https://www.citusdata.com/blog/2016/09/22/announcing-citus-mx/ https://www.citusdata.com/blog/2016/09/22/announcing-citus-m...