
Landlord: Per-Tenant Stats in Postgres with Citus - brightball
https://www.citusdata.com/blog/2018/07/31/introducing-landlord-per-tenant-stats/
======
sam0x17
Love Citus's technology, but once again $99/month is ridiculous for a "dev"
plan. Small startups want to use the same database from the pre-MVP dorm room
phase all the way through their Series A, and while your technology would
theoretically allow that, your pricing closes a lot of doors. No one wants to
switch databases once their product is doing well enough to warrant $99/month
for a database, so you are scaring away a lot of potential customers such as
myself.

Once again I implore you to consider adding a "starter" or "hobbyist" tier for
$20/month or even $5/month. If you want to really be competitive, your product
should be free to use until you have more than 200mb of data stored in your
database, at which point usage-based pricing kicks in based off of the number
of rows used.

~~~
craigkerstiens
It's helpful feedback, and something we'd love to work towards some day. The
short of it is because of Citus architecture it does require multiple
underlying nodes and there is some overhead that until you get to a larger
scale Citus doesn't necessarily make sense. If you've only got 10 GB of data a
single node instance on RDS should suit you just fine.

We understand some of the costs of switching and have actively been working to
build tools for you to plan to use something like Citus, but then migrate when
the time comes. Libraries like activerecord-multi-tenant or django-multi-
tenant ensure you're ready for Citus and work perfectly well on a single node
Postgres database.

Then when the time comes, which could be at $100 of RDS or $500 of RDS or
larger, we have Citus warp [1] that allows you in a fully online way to
replicate from RDS directly into a Citus cluster. Using it we've had customers
with > 4 TB of data cutover with less than a minute of impact to their
database.

I know that's not as simple as starting on Citus and continuing to scale, so
hopefully we can address this better in the future, but for now it's the best
answer we have at the moment.

[1]. [https://www.citusdata.com/blog/2017/12/08/citus-warp-pain-
fr...](https://www.citusdata.com/blog/2017/12/08/citus-warp-pain-free-
migrations/)

~~~
sam0x17
You could, for example, offer a plan that starts out extremely cheap, uses
usage-based pricing, and only has Citus technology kick in when you reach the
relevant scale. So < 10 GB it would just be a normal PostgreSQL node. I would
use this for everything if it was like that.

------
danharaj
I respect Citus for the way they consistently praise the PostgreSQL community
when promoting themselves.

------
jedberg
Heh I thought this was for landlords to track tenant data. I was excited for a
second!

~~~
mipmap04
Just curious - what sort of data would you want to track on tenants?

~~~
dominotw
Noise levels would be good. When I am moving this noise is a total wildcard
and luck. I would pay a premium to move in with less noise neighbours and
possibly quite tenants can be rewarded with that premium.

~~~
krisroadruck
I know I'd pay extra not to have to live next to neighbors with small children
or yappy dogs. Still annoyed that it's illegal for there to be childless
apartment communities.

~~~
dragonwriter
> Still annoyed that it's illegal for there to be childless apartment
> communities.

It's not, you are just probably not old enough for the ones that are legal.

~~~
tpetry
Who doesn‘t love a session of bingo at the afternoom? :)

------
hemancuso
I’d love to know if anyone here has done a deep eval of Citus vs CockroachDB.
They seem to be the two most promising solutions for horizontal scale-out
Postgres and both are under very active development.

~~~
qaq
?? outside of CockroachDB using PostgreSQL wire protocol they focus on very
different use cases it seams. from CocroachDB website: "When is CockroachDB
not a good choice? CockroachDB is not a good choice when very low latency
reads and writes are critical; use an in-memory database instead.

Also, CockroachDB is not yet suitable for:

Heavy analytics / OLAP"

I think Citus is actually very well suited for Heavy analytics / OLAP

~~~
craigkerstiens
At Citus we tend to focus on two use cases:

1\. Analytical, but less data warehousing and more of a HTAP (hybrid
transactional/analytical processing). In this case you're often ingesting a
lot of data, often times sensor or log data from many endpoints, and then
providing analytics across that data. The analytics needs to be up to date
within minutes, and responsiveness of reports within seconds. You can see how
Algolia (which powers the search for HN) uses Citus for this in their blog
post - [https://blog.algolia.com/building-real-time-analytics-
apis/](https://blog.algolia.com/building-real-time-analytics-apis/)

2\. Transactional. For a couple of years now Citus has had full transactional
support when targeting a single node. Single node transactions can actually
cover a breadth of use cases because it can span across tables as long as
tables are co-located within the same node. We often see this is the case for
multi-tenant/SaaS applications. In recent releases we also added support for
distributed transactions. These transactions do have a higher overhead, but
can often be hard to detangle from an existing application, thus us building
support for distributed deadlock detection then adding distributed
transactions.

Generally we're continuing to improve and support both of those use cases and
have our usage base actually pretty evenly split between the two.

~~~
hemancuso
Can you say anything to help understand the differences between cockroach and
Citus?

------
brightball
I wonder if/when Citus will have a GCP option?

~~~
craigkerstiens
Hi, Craig from Citus here. We're always continuing to explore other platforms
beyond Citus Cloud on AWS. Stay tuned for the future as we'll add support for
others. The input and feedback on which platforms people prefer is very
helpful, so always feel free to drop us a note directly on that.

~~~
manigandham
+100 for GCP

~~~
ci5er
Why? Yes, AWS can be expensive for performance, but it scales well and is
automatable. I 'get' why no Azure for greenfield, but why do you love GCP?

~~~
thangngoc89
when the rest of your infrastructure is already on GCP, running the database
on the same cloud would reduce latency and bandwidth cost

~~~
ci5er
Well, sure.

I guess the broader question would be: Why use GCP? I like them well enough,
but I find it easier to prototype on AWS. Why would a developer develop the
MVP on GCP vs AWS and then go to scale there? (I realized that K8S has made
this, recently, a moot point, and it comes down to cost ... but beside that is
there anything?)

EDIT: I realize that as a neo-Luddite, I just might be used to AWS, and would
be open (mostly) to arguments to move to GCP if it is better (I'm not not
talking about $/Gbps)

EDIT2: As a (mostly) fan of Google - I probably would have gotten myself
acclimatized to their platform if it was any good 10 years ago, but it wasn't,
so I didn't, and I guess I'm asking: is there a good reason to learn how to
switch?

~~~
manigandham
That's a broad question for a side topic...

GCP has better performance (especially raw storage, compute and network),
cheaper and simpler pricing, and more consistent experience. The raw
primitives to build with are better designed and integrated, and scale without
any tuning.

We're not building MVPs (which are just as easy) but have a working product
and only use GKE and VMs. If you need all the managed services then AWS is the
right choice, but K8S has made that a non-issue for us and allows us to use
VMs (which are the most reliable part of any cloud), along with
spot/preemptible pricing and better colocation for efficiency.

~~~
ci5er
I don't use managed services, because I want portability, but you are right
(and as I think I said upstream) K8S has made many of the issues in production
moot.

You say that you find that prototyping is as easy with GCP as with AWS? Do you
believe it is because you are familiar with GCP? Or do you believe that they
are truly at par with prototyping productivity?

(And yes - we've gone far afar of the upstream topic - but I do appreciate
your feedback)

~~~
manigandham
I dont know what you consider as prototyping, but yes they both can run a
basic app with minimal effort.

Look into AppEngine which is a few CLI commands for deploying. Same with
Firebase which is widely considered a great mobile platform with everything
you need. You can also use the Serverless.com framework to build apps on Cloud
Functions, and they recently announced running any container in a serverless
fashion (similar to Azure's ACI).

If you still want to run servers, then they have the best VM platform around.

