Re: Using Postgresql as application server - Mailing list pgsql-admin
From | Evan Rempel |
---|---|
Subject | Re: Using Postgresql as application server |
Date | |
Msg-id | 4E4A9A83.2070702@uvic.ca Whole thread Raw |
In response to | Re: Using Postgresql as application server (Scott Marlowe <scott.marlowe@gmail.com>) |
Responses |
Re: Using Postgresql as application server
Re: [GENERAL] Using Postgresql as application server Re: [GENERAL] Using Postgresql as application server |
List | pgsql-admin |
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@bestmx.ru <sad@bestmx.ru>: >> Scott Marlowe ÐÉÛÅÔ: >>> On Mon, Aug 15, 2011 at 11:33 AM, sad@bestmx.ru<sad@bestmx.ru> šwrote: >>>> Scott Marlowe ÐÉÛÅÔ: >>>>> On Sat, Aug 13, 2011 at 9:57 AM, c k<shreeseva.learning@gmail.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. >
pgsql-admin by date: