What does HackerNews think of activerecord-multi-tenant?

Yup! I lean towards a tenant ID approach. I ALWAYS use a library that enforces these tenant checks on queries. Ruby (https://github.com/citusdata/activerecord-multi-tenant) and Elixir (I wrote https://github.com/sb8244/ecto_tenancy_enforcer) are the ones I have experience with.

The off the shelf Postgres drivers work. We're a pure Postgres extension so you don't need anything exotic there just a standard Postgres driver. When it comes to the application side of things it depends a little bit more there on how you may structure your queries. To help out there we have a few libraries (for Rails[1] and Django[2]) and more coming.

[1] https://www.citusdata.com/blog/2017/11/14/scale-out-your-dja...

[2] https://github.com/citusdata/activerecord-multi-tenant

Craig from Citus here. Thanks for the kind words Justin, as you mention there is some upfront work, but once it's in place it becomes fairly manageable.

We've been working to make that upfront work easier as well with libraries that allow things to be more drop-in (ActiveRecord-multi-tenant: https://github.com/citusdata/activerecord-multi-tenant and Django-multitenant: https://github.com/citusdata/django-multitenant)

Timeframes for sharding projects vary quite a bit. If you have a B2B database, we find that sharding projects usually take between one to eight weeks of engineering (not clock) time. Most take two to three weeks.

A good way to tell is by looking at your database schema. If you have a dozen tables, you'll likely migrate with one week's of effort. If your database has 250+ tables, then you'll take about eight weeks.

When you're looking to shard your B2B database, you usually need to take the following steps:

1. Find tables that don't have a customer / tenant column, and add that column. Change primary and foreign key definitions to include this column. (You'll have a few tables that can't have a customer column, and these will be reference tables)

2. Backfill data to tables that don't didn't have customer_id / tenant_id

3. Change your application to talk to this new model. For Rails/Django, we have libraries available that make the app changes simpler (100-150 lines). For example: https://github.com/citusdata/activerecord-multi-tenant

4. Migrate your data over to a distributed database. Fortunately, online data migrations are starting to become possible with logical decoding in Postgres.

If you have a B2C app, these estimates and steps will be different. In particular, you'll need to figure out how many dimensions (columns) are central to your application. From there on, you'll need to separate out the data and shard each data group separately.