Re: Multi-tenancy in Postgres

I think Greg might be forgetting that some of us don't always get to
choose what we work on.  I was in a shop that decided to go with
multi-tenancy for reason both technical and um, er envious. One schema
to update versus n, for an example of the former.  Amazon does it, for
the other example.  But at the end of the day I believe the "shot
callers" simply wanted to have "multi-tenant" on a power-point slide.
We went down the vpd-route with veils, but only to proof of concept.
Speaking of which, has that project simple withered on the vine?

On 06/28/2011 03:03 PM, Greg Smith wrote:
> Emrul Islam wrote:
>> I've just read through a paper here:
>> http://www.edbt.org/Proceedings/2011-Uppsala/papers/edbt/a12-schiller.pdf
>> about multi-tenancy.
>>
>> They used Postgres for their work and while it is academic and would
>> need further work I'm just wondering if anyone in the Postgres team
>> is looking at implementing some of the functionality described?
>
> They seem fuzzy about what actual businesses who implement
> multi-tenant environments, such as hosting companies, actually want
> and find missing in PostgreSQL right now.  They've tried to solve a
> problem I never would have considered interesting in the first place.
>
> On the "Shared Machine" side of things, we find complaints like how
> individual PostgreSQL instances use too much power.  See "Latch
> implementation that wakes on postmaster death", currently under
> development aimed at 9.2, aimed right at kicking that one around.
>
> This "Shared Table" approach they spend so much time worrying about
> and improving?  No one cares about that except companies hosting a
> single application on their giant box.  This idea that there are large
> number of tenants running the same application, but whom need to be
> isolated from one another in some way, is not the normal state of
> things.  Yes, it happens on the big servers at Salesforce.com who all
> run the same application; that is not a common situation however.
>
> What the hosting companies actually want from PostgreSQL is a good
> implementation of "Shared Process".  One database install, every
> tenant gets their own schema, tables and are expected to use some
> resources.  You can do this right now; I believe the infrastructure at
> Heroku is built that way for example.  How do the ideas in this paper
> actually solve the problems they're seeing with that approach?  I
> don't know for sure, but I don't see anything exciting there.
>
> I makes me kind of sad when people put a lot of work into doing a good
> job on a problem that doesn't really matter very much in the real
> world, and that's the overwhelming feel I get from reading this
> paper.  Advanced schema inheritance stuff?  Don't care.  Providing
> query cost constraint limits for individual tenants?  Now that's a
> useful problem to talk about, one that people deploying multi-tenant
> databases are actually being killed by.  And discussing aspects of
> that problem does flare up among the PostgreSQL developers regularly.
>