Re: Using Postgresql as application server

From: Evan Rempel <erempel(at)uvic(dot)ca>
To: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
Cc: "sad(at)bestmx(dot)ru" <sad(at)bestmx(dot)ru>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, pgsql-admin <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Using Postgresql as application server
Date: 2011-08-16 16:27:47
Message-ID: 4E4A9A83.2070702@uvic.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-general

Technically it can be done, but just because we can do something does not
mean we should do something. Having said that...

We have been using a middleware product that shall remain nameless,
that goes against a large commercial database that shall also remain nameless.
The middleware has been migrating to a more and more database based code
set, and as an administrator of such a system I can state that this is
awful.

Getting appropriate logging out of the application logic for both auditing purposes
and trouble shooting is near impossible. Performance is nearly impossible to tune as
everything runs inside the database. One giant process chewing up cores of CPU power.

Security is near impossible to manage as well. Again, almost everything needs to run as
the same user. The database is now making calls to generate pdf objects and make
printing calls.

None of the traditional tools can be used to integrate the application into the enterprise.
The load balancer needs to add x-forwarded headers to http requests, but the
custom http code can't handle that, so all web access appears to come from the load
balancer. This violates regulatory requirements. Log file formats are not standard
since none of the code is standard, this means that none of the event correlation
tools can be used for intrusion detection etc.

It is just a nightmare. The previous version that had real middleware and real database
servers was much better. The workloads were different so each server could be tuned for
what it was doing. We were able to purchase hardware appropriate to the task. Big RAM
for database, big CPU for middleware. Overall it was cheaper.

Just my $0.02

Evan

Scott Marlowe wrote:
> 2011/8/16 sad(at)bestmx(dot)ru <sad(at)bestmx(dot)ru>:
>> Scott Marlowe ÐÉÛÅÔ:
>>> On Mon, Aug 15, 2011 at 11:33 AM, sad(at)bestmx(dot)ru<sad(at)bestmx(dot)ru> šwrote:
>>>> Scott Marlowe ÐÉÛÅÔ:
>>>>> On Sat, Aug 13, 2011 at 9:57 AM, c k<shreeseva(dot)learning(at)gmail(dot)com>
>>>>> šwrote:
>>>>>> Dear Postgres users,
>>>>>> from last few months I am reading and searching for can postgresql used
>>>>>> as
>>>>>> application server? As postgresql supports many languages like pl/perl,
>>>>> Besides the previously mentioned nginx module there's apache's mod
>>>>> libpq http://asmith.id.au/mod_libpq.html
>>>>>
>>>>> But I'd stick to a language to wrap stuff in like php etc.
>>>> BTW, string concatenation in postgresql (plpgsql) is FASTER than in PHP
>>> But I can throw 1,000 cores at a large load with php. šMuch harder to
>>> do with plpgsql.
>> and?
>> all of them would inevitably connect the same postgresql
>
> And they'd each need postgresql to do a concat? I'd hope nobody was
> dumb enough to program the app layer to do something like that. PG
> might make a decent app server, but there's no way you could scale it
> to millions of users like you could a farm of app servers.
>

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message sad@bestmx.ru 2011-08-16 16:55:27 Re: Using Postgresql as application server
Previous Message Scott Marlowe 2011-08-16 15:44:14 Re: Using Postgresql as application server

Browse pgsql-general by date

  From Date Subject
Next Message sad@bestmx.ru 2011-08-16 16:55:27 Re: Using Postgresql as application server
Previous Message Scott Marlowe 2011-08-16 15:44:14 Re: Using Postgresql as application server