On Sat, Oct 01, 2016 at 07:21:47PM -0400, Melvin Davidson wrote:
> *I would like to comment on the multiple schema vs databases situation.
> First of all, 1000's of databases is insanity and just asking for trouble.
> Next, 1000's of schemas is a nightmare to maintain. I understand the
>
On 30/09/2016 18:45, Rakesh Kumar wrote:
I've been reading this discussion with great interest, to see what other
Postgres experts think. :-)
I am bit disappointed that most of the replies are questioning why we are
doing what we are doing. Once again, we (db designers) have no choice
in that.
>do you run a separate instance of the app for each tenant, or is there one app
>that identifies the
>tenant and handles them accordingly ?
Each tenant will have different app server. there will be persistent connection
for each tenant.
--
Sent via pgsql-general mailing list
On Sat, Oct 1, 2016 at 4:52 PM, John R Pierce wrote:
> On 10/1/2016 12:52 PM, Rakesh Kumar wrote:
>
> Do your clients authenticate directly to the database, or to the app server?
>
> thru app server.
>
>
> do you run a separate instance of the app for each tenant, or is
On 10/1/2016 12:52 PM, Rakesh Kumar wrote:
Do your clients authenticate directly to the database, or to the app server?
thru app server.
do you run a separate instance of the app for each tenant, or is there
one app that identifies the tenant and handles them accordingly ?
--
john r
On 10/1/2016 11:39 AM, Jeff Janes wrote:
As others have said, different databases makes connection pooling less
efficient, which could be very important to you, or could be irrelevant.
1000 apps running at once each with their own DB and 10s of connections
== 10s of 1000s of database
>Are you restoring because your whole system failed, or because one client did
>something
>wrong and needs just their data rolled back?
Chances of restoring just for one client will probably be 99% of use cases.
> Do your clients authenticate directly to the database, or to the app server?
On Thu, Sep 29, 2016 at 12:18 PM, Rakesh Kumar
wrote:
>
> Hi
>
> I would like to know which technique is better for supporting
> multi-tenancy=
> applications, going upto hundreds or even thousands of tenants.
>
> 1 - One database with difference schemas (one schema
I don't know if that's helpful to you or not, but hopefully it was at least a
little.
===
yes it was. thanks
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
>> I've been reading this discussion with great interest, to see what
>> other Postgres experts think. :-)
>
>I am bit disappointed that most of the replies are questioning why we are
>doing what we are doing. Once again, we (db designers) have no choice in that.
> What I would like to know
>Then you need different clusters per tenant. Otherwise, the WAL records
> of different tenants are inextricably mingled together.
Yes we are aware of it .This part is OK as it is not deemed as user table data.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
* Jeff Janes (jeff.ja...@gmail.com) wrote:
> On Fri, Sep 30, 2016 at 2:06 AM, Rakesh Kumar
> wrote:
> > We require complete data isolation. Absolutely nothing should be shared
> > between two tenants.
>
> Then you need different clusters per tenant. Otherwise, the
On Fri, Sep 30, 2016 at 2:06 AM, Rakesh Kumar
wrote:
>
> We require complete data isolation. Absolutely nothing should be shared
> between two tenants.
>
Then you need different clusters per tenant. Otherwise, the WAL records of
different tenants are inextricably
> I've been reading this discussion with great interest, to see what other
> Postgres experts think. :-)
I am bit disappointed that most of the replies are questioning why we are
doing what we are doing. Once again, we (db designers) have no choice
in that. What I would like to know that which
On Fri, Sep 30, 2016 at 6:06 AM, Rakesh Kumar
wrote:
A typical fear mongering Q from
them "what if due to a bug in your s/w, our competitors end up looking at our
data" or
something like that. That's why schema level vs db level discussion.
I've been reading this
Rakesh,
As long as one application knows how to connect to more than 1 tenant,
there will *always* be the possibility that a software bug in your
application causes one tenant to access another tenant's data. I think this
is why you're getting people asking you to refine your requirements. There
On Fri, Sep 30, 2016 at 5:11 AM, John R Pierce wrote:
> On 9/30/2016 2:06 AM, Rakesh Kumar wrote:
>>
>> We require complete data isolation. Absolutely nothing should be shared
>> between two tenants.
>>
>> WHy would multiple dbs be any worse than multiple schemas in
On Fri, Sep 30, 2016 at 6:06 AM, Rakesh Kumar
wrote:
> A typical fear mongering Q from
> them "what if due to a bug in your s/w, our competitors end up looking at our
> data" or
> something like that. That's why schema level vs db level discussion.
So... if your
ent: Friday, September 30, 2016 02:48
>> To: Rakesh Kumar
>> Cc: pgsql-general@postgresql.org
>> Subject: Re: [GENERAL] Multi tenancy : schema vs databases
>>
>> On Fri, Sep 30, 2016 at 10:16 AM, Rakesh Kumar <
>> rakeshkumar...@outlook.com<mailto:rakes
> ok, thats ridiculous, isn't it. so now its time to find a compromise.
You don't understand how sales people pitch our products. We deal with
financial data
and our customers are extremely sensitive to even imagining that their data
will co-reside
with that of their competitors who also are
ag1...@gmail.com>
Sent: Friday, September 30, 2016 02:48
To: Rakesh Kumar
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Multi tenancy : schema vs databases
On Fri, Sep 30, 2016 at 10:16 AM, Rakesh Kumar
<rakeshkumar...@outlook.com<mailto:rakeshkumar...@outlook
On 9/30/2016 2:06 AM, Rakesh Kumar wrote:
We require complete data isolation. Absolutely nothing should be shared between
two tenants.
WHy would multiple dbs be any worse than multiple schemas in performance?
complete? use 1000s of seperate VM instances, one per tennant.
ok, thats
From: Venkata B Nagothi <nag1...@gmail.com>
Sent: Friday, September 30, 2016 02:48
To: Rakesh Kumar
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Multi tenancy : schema vs databases
On Fri, Sep 30, 2016 at 10:16 AM, Rakesh Kumar
<ra
resql.org
> Subject: Re: [GENERAL] Multi tenancy : schema vs databases
>
> On Fri, Sep 30, 2016 at 5:18 AM, Rakesh Kumar <rakeshkumar...@outlook.com<
> mailto:rakeshkumar...@outlook.com>> wrote:
>
> Hi
>
> I would like to know which technique is better for sup
On 9/29/2016 2:25 PM, Venkata B Nagothi wrote:
Since, you are saying there could be thousands of tenants, going for
single-database-per-tenant could possibly end up in a very bad and
complex database design.
worse, it would also require each tenant to have unique connections,
making
From: Venkata B Nagothi <nag1...@gmail.com>
Sent: Thursday, September 29, 2016 17:25
To: Rakesh Kumar
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Multi tenancy : schema vs databases
On Fri, Sep 30, 2016 at 5:18 AM, Rakesh Kumar
<ra
On Fri, Sep 30, 2016 at 5:18 AM, Rakesh Kumar
wrote:
>
> Hi
>
> I would like to know which technique is better for supporting
> multi-tenancy=
> applications, going upto hundreds or even thousands of tenants.
>
> 1 - One database with difference schemas (one schema
Hi
I would like to know which technique is better for supporting multi-tenancy=
applications, going upto hundreds or even thousands of tenants.
1 - One database with difference schemas (one schema per tenant)
or
2 - One database per tenant.
The points to be considered are:
1 - which is more
28 matches
Mail list logo