3 ms·

> But that's enterprise: even if we're widely successful, we'll have "thousands" of customers - never millions. And we can manage thousands of databases, so thi

by mbesto 10y ago

> But that's enterprise: even if we're widely successful, we'll have "thousands" of customers - never millions. And we can manage thousands of databases, so this architecture path is preferable to us within those boundaries. Exactly. Unless you're ACV is $100k+ this is strategy isn't really sustainable and might materially impact your gross margins. EDIT: Further, read the more technical limitations of this approach: https://news.ycombinator.com/item?id=12652021 https://news.ycombinator.com/item?id=12652021

icebraining 10y ago
Exactly. Unless you're ACV is $100k+ this is strategy isn't really sustainable and might materially impact your gross margins. Why? We have customers with ACVs under $10k (even after adjusting for cost of living/general prices level) with this model. We simply automated the whole process, so the clients can register for our service and get a new database (created from a template) without any manual intervention.
- mbesto 10y ago
  Good luck with schema migrations and backups when you hit 1,000 customers (see Citus rep's comment).
  - icebraining 10y ago
    I think they're talking about one-schema-per-tenant, not one-database-per-tenant like e1g. Still, we'll never hit anything close to 1000 customers per server, we distribute them over more servers instead. In fact, that's an advantage of this model over the single-database one: since every tenant is isolated, the model is perfectly horizontally scalable. You can simply fill up servers without worrying about massively distributed databases or datacenter-wide load balancing. Hell, we just migrated across hosting providers with barely breaking a sweat: we simply moved machine by machine without ever worrying about latency between DCs and all that.
    - mbesto 10y ago
      But if your schema changes, it means you have to do a migration to N databases (N being the number of customers you have). If you have to update your database from PG 9.0 to PG 10.0, you have to do N times. And so on. You'll have N number of backups that all have to be stored individually. Etc etc.

by mbesto 10y ago

icebraining 10y ago

Exactly. Unless you're ACV is $100k+ this is strategy isn't really sustainable and might materially impact your gross margins. Why? We have customers with ACVs under $10k (even after adjusting for cost of living/general prices level) with this model. We simply automated the whole process, so the clients can register for our service and get a new database (created from a template) without any manual intervention.

mbesto 10y ago
Good luck with schema migrations and backups when you hit 1,000 customers (see Citus rep's comment).
- icebraining 10y ago
  I think they're talking about one-schema-per-tenant, not one-database-per-tenant like e1g. Still, we'll never hit anything close to 1000 customers per server, we distribute them over more servers instead. In fact, that's an advantage of this model over the single-database one: since every tenant is isolated, the model is perfectly horizontally scalable. You can simply fill up servers without worrying about massively distributed databases or datacenter-wide load balancing. Hell, we just migrated across hosting providers with barely breaking a sweat: we simply moved machine by machine without ever worrying about latency between DCs and all that.
  - mbesto 10y ago
    But if your schema changes, it means you have to do a migration to N databases (N being the number of customers you have). If you have to update your database from PG 9.0 to PG 10.0, you have to do N times. And so on. You'll have N number of backups that all have to be stored individually. Etc etc.