Citus 11 is out! Now 100% open source. Read all about it in Marco’s release blog. 💥
Are your database queries taking too long?
Do you have more data than you can store in single-node Postgres?
Are you worried about whether your database infra can handle new customer signups?
Are you worried you might have to give up SQL in order to scale out your database?
Does your database performance deteriorate with a high number of concurrent requests?
Are lots of your developers spending time micro-optimizing your database?
Are you looking for a way to scale that doesn’t require your engineers to figure out sharding?
Is it taking you too long to analyze metrics across your customer base?
Is your largest customer creating performance issues for the rest of your customers?
Most SaaS applications are inherently relational. By sharding on customer_id, Citus gives you the ability to scale out your SaaS database with full SQL coverage, so you don’t have to give up the relational semantics you need, like joins, foreign key constraints, transactions, ACID, consistency. By scaling out, your app gets much bigger memory, compute, and disk footprint—ensuring performance even in the face of growth. And since Citus is an extension to Postgres, you can leverage all of your existing expertise—plus all the Postgres reliability, rich data types (think: JSON and PostGIS), Postgres extensions (our favorites include HyperLogLog), and ongoing innovation in the amazing Postgres open source community.
So you want a database that can handle peak workloads and boatloads of concurrent users; act as a system of record and provide business analytics; offer high availability and provide elastic scale as your customer base triples in size. Check. The icing on the cake is for the database to integrate seamlessly with your frameworks like Rails, Django, Hibernate, and Sequelize. Because Citus is an extension to Postgres, we’ve been able to build on top of the robust, existing Postgres integrations and make it easy for multi tenant apps to use Citus: recent additions include an activerecord-multi-tenant gem for Ruby on Rails, and a Python django-multitenant library for Django. More to come.
While you may have a lot of data and your SaaS database may soon be too big for single-node Postgres, it’s likely that any given customer of yours can get the database performance they need from a single node. With our Citus extension to Postgres, the database is scaled out and yet data for each of your SaaS customers is
A Citus database cluster includes a coordinator node and multiple worker nodes, with Postgres and Citus installed on each node. With HA turned on in Citus Cloud secondary nodes exist, too. Citus shards the database based on the distribution key, and distributes the shards across the worker nodes. Meanwhile, the coordinator stores metadata about the shards. All of your queries are executed via the Citus coordinator node, which transforms the query into smaller fragments that can be run independently on individual shards. The pièce de résistance: Because Citus can parallelize query fragments across multiple nodes in a cluster, you can run powerful cross-shard queries across all of your customer data quickly and easily.
Citus is available as Hyperscale (Citus), a
We expected a database migration to be a huge code change, requiring a lot of rewrites. But Citus has a Django multi-tenant library, which minimized the refactoring to migrate our application. Except for rewriting a few lines of our app, we ended up using pretty much the same code.Shashank Kumar, Founder, PushOwl