Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>- Data isolation by either physical separation (i.e. separate database) or logical separation (i.e. separate schema, table, or column association) depending on requirements

It's interesting to me that you and @abraae seem to take the exact opposite view on the topic of data isolation where he/she has a much... harsher opinion:

>We took the decision to use separate databases (schemas in the Oracle world) ... I now think of this approach as maybe getting into heroin (no direct experience). Feels great, powerful, you can do anything. But ultimately it will kill you.

Of course this doesn't apply to the case of column association, but I'm interested on your take on this.



(He/him).

If your app is super-sensitive and absolute security is an absolute must then sure, using a separate database for every customer will help you answer those pesky security questions "How do you ensure that resources are not accessed by other tenants?".

My experience though is that if you are after velocity, and ease of maintenance, then you need a single database and tables with a "tenant id" column in them.

Even simple things get hard when you have separate databases. Say I want to know how many customers have how many widgets on average. If everyone's in one database, that's a SQL query. If they're all separate, it's ten times harder to answer.


This isn’t possible if you’re expecting all transactions to be in a single table, at some point you’re going to have to share things making any query at scale more complex.


Can you clarify? You can vertically scale a database a few orders of magnitude. My view is that “some point” is a long way off for most OLTP workloads.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: