Citus 10 is out! New features include columnar storage & Citus on a single node—plus we’ve open-sourced the shard rebalancer. Read the Citus 10 blog.

Skip navigation

Citus Newsletter

Archive for November 2016

Made with    from the Postgres team at Microsoft

Citus 6.0 allows you to scale out your transactional relational database with minimal changes to your application, thus reducing complexity over other alternatives while still allowing scale. If you’re building a multi-tenant application and outgrow a single node Postgres, by sharding based on tenant with Citus 6.0 you can linearly add more memory and processing power to your database without a large re-architecting of your application. You can still maintain referential integrity, and to your application it’s still just standard Postgres. Give it a try on Citus Cloud today.

We’re excited to be at Re:Invent this coming week and we look forward to seeing many of you there. If you’re traveling to Vegas for the conference stop by and check out our booth, number 220, and consider attending our talk: How Citus enables scalable Postgres on AWS.

Last week PGConf Silicon Valley was held. It was a great collection of Postgres community members and Postgres users. We’ll have some highlights and recap of it in coming weeks, but one exciting bit of news to come out of it is that next year PGConf Silicon Valley is merging with PostgresOpen. This aims to bring together an even bigger and better Postgres conference, happening in the fall of next year in Silicon Valley.
On the Blog

Webcast recap: Scaling your SaaS Database with Postgres
If you missed our webcast last month on designing your SaaS database for scale don’t worry you can still catch up on the content. Within the presentation we covered a number of topics including why scale your SaaS (multi-tenant) database, various design patterns for scaling, and architectures for scale. You can find the recording and slides available on our blog.
Postgres Autovacuum is Not the Enemy
It’s a common misconception that high volume read-write workloads in PostgreSQL inevitably causes database inefficiency. We’ve heard of cases where users encounter slowdowns doing only a few hundred writes per second and turn to systems like Dynamo or Cassandra out of frustration. However PostgreSQL can handle these workloads without a problem as long as it is configured correctly. Read about what you need to know to tune it properly and what vacuum actually does for you under the covers.

Subscribe to the Citus Newsletter

Join over 12,000 subscribers today

Made with    from the Postgres team at Microsoft