If you missed our talk, How Citus Enables Scalable PostgreSQL on AWS, at AWS re:Invent you can catch the recording-now online. Within the talk one of our principal engineers, Will Leinweber, gives a brief overview Citus, best use cases for it, and a drill down into how it’s run and managed as a hosted service on top of AWS. The orchestration is homegrown, but comes from years of experience of running millions of Postgres databases on top of AWS.
Citus is commonly used to scale out event data pipelines on top of PostgreSQL. Its ability to transparently shard data and parallelise queries over many machines makes it possible to have real-time responsiveness even with terabytes of data. Users with very high data volumes often store pre-aggregated data to avoid the cost of processing raw data at run-time. With Citus 6.0 this type of workflow became even easier using a new feature that enables pre-aggregation inside the database in a massively parallel fashion using standard SQL. Learn more how simple it can be to built your own real-time event roll-up system with Citus 6.0 in this post.
If you’re on Heroku and you’re looking to get started with Citus our add-on is now generally available. Give it a try today, perhaps kick the tires with one of our tutorials. If you’re looking for a more production tier plan, those are available as well, just drop us a line.
PGConf Silicon Valley wrapped up a little more than a month ago. It was a great conference with lots of community members and fans of Postgres. If you missed it though don’t worry, we’ve captured the talks for you so you can still partake of all the knowledge that was shared. Give this video set a look to see if there’s something that can be of help to you.
When we open sourced Citus we heard a lot of questions about how Citus replicates data and automates node failovers. In this blog post, we intend to cover the two replication models available in Citus: statement-based and streaming replication. We also plan to describe how these models evolved over time for different use cases..
When you want to scale out though, you want it to be simple. For scaling a multi-tenant database, there’s three common approaches: create a database per tenant, create a schema per tenant, have all tenants share the database tables. Recently one of the authors of a popular library, apartment–a rails gem, which makes it easier to shard with schemas blogged about their experiences. It’s a great read of some of their lessons learned from the experience.
