Craig Kerstiens

Microservices and NoSQL get a lot of hype, but in many cases what you really want is a relational database that simply works, and can easily scale as your application data grows. Microservices can help you split up areas of concern, but also introduce complexity and often heavy engineering work to migrate to them. Yet, there are a lot of monolithic apps out that do need to scale. If you don't want the added complexity of microservices, but do need to continue scaling your relational database then you can with Citus. With Citus 6.1 we're continuing to make scaling out your database even easier with all the benefits of Postgres (SQL, JSONB, PostGIS, indexes, etc.) still packed in there.

With this new release customers like Heap and ConvertFlow are able to scale from single node Postgres to horizontal linear scale. Citus 6.1 brings several improvements, making scaling your multi-tenant app even easier. These include:

• Integrated reference table support
• Tenant Isolation
• View support on distributed tables
• Distributed Vaccum / Analyze

All of this with the same language bindings, clients, drivers, libraries (like ActiveRecord) that Postgres already works with.

Give Citus 6.1 a try today on Citus Cloud, our fully managed database-as-a-service on top of AWS, or read on to learn more about all that’s included in this release.

Your database is a key part of your stack, and when things act up in your application getting insights into it are key. With Citus Cloud you have a number of dashboards with metrics you can look into as well as centralized logging. In addition to the centralized logging, you also have the ability to drain your logs to the provider of your choice. This means you can have all your Citus Cloud logs (both the coordinator and distributed nodes) integrated with the rest of your application logs.

We're excited to announce U2F Fido (Yubikey) support for Citus Cloud to make the experience of keeping your account and data secure even easier. Within the Account Security section of the Citus Cloud Console you'll now see a section to add your new device. If you already have a U2F click Register New Device then you'll be prompted to activate it, and you're done.

If you already have a Yubikey then you know all the benefits it brings, however when testing many of our customers were unaware of them or weren't using them already. We felt it would be worth it to spend some time explaining why they're great as well as creating a few guides for how to set them up on the most common services you may be using.

Getting an example schema and data is often one of the more time consuming parts of testing a database. To make that easier for you, we're going to walk through Citus with an open data set which almost any developer can relate to–github event data. If you already have your own schema, data, and queries you want to test with, by all means use it. If you need any help with getting setup, join us in our Slack channel and we'll be happy to talk through different data modeling options for your own data.

An overview of the schema and queries

The data model we're going to work with here is simple, we have users and events. An event can be a fork or a commit related to an organization and of course many more.

We talk with a number of Postgres users each week that are looking to scale out their database. First, we would never recommend scaling out until you truly have to, it’s always easier to scale your database up rather than out. It’s often not until over 100 GB of data that you need to think about sharding.

When you want to scale out though, you want it to be simple. For scaling a multi-tenant database, there’s three common approaches:

When we started PGConf Silicon Valley we started it with the goal of helping to grow the Postgres community like many of the other conferences out there with a focus on a large scale west coast event. In our first two years of running the conference...

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.

We recently presented a webcast on when and what to consider when scaling your multi-tenant application. In case you missed it, the recording and slides are below. Within the webcast session, we cover:

PGConf Silicon Valley, November 14-16, is barely under a month away and it's shaping up to be another great conference this year. Last year we had over 300 attendees to make it one of the larger Postgres conferences around, and this year we're expecting...

In any as-a-service business, which bills monthly, a key metric you track is MRR or monthly recurring revenue. It's good practice to have this on a dashboard and check it on a monthly, weekly, or even daily basis. If you have a simple pricing model that has set monthly plans, say like Netflix this is pretty easy to calculate:

SELECT sum(user_subscriptions.price)
FROM user_subscriptions
WHERE users_subscriptions.ended_at IS null;

The above will give you the run rate as of this exact moment in time. It gets a little more complicated to do this in a single query that gives it to you over time.