Postgres and 3-tier Webapps

I gave a presentation last week on using the features
of databases, such as Postgres, in Web applications.
Specifically, my point was moving business logic into
the database using stored procedures, triggers, etc.
is better than typical PHP-based Webapps that embed
the business logic into the Web pages - mixed in with
presentation logic.

There was a critic of this technique who advocated
using a 3-tier design instead. This places business
logic in a layer (middleware) between the presentation
logic of the Webapp and the database.

Among the disadvantages of the 2-tier design I was
advocating, he pointed out that I was tying my app
to Postgres. He suggested that 1) Postgres might not
be available in the future, and 2) I might want to
migrate to another database, such as Oracle.

I had already considered point 2 and researched the
effort it would take to convert Postgres stored
procedures to Oracle. The differences between PL/pgSQL
and PL/SQL do not seem to be that great to me. Converting
my typical site may take a few days (My presentation
did not focus on major Web sites. I wasn't advocating
a 2-tier design for, say, Amazon.com)

It seems to me that developing the middle tier to handle
the business logic and the abstractions that allow more
flexible interfaces to underlying databases would take
far longer than to build the business logic into the
database and, possibly, having to convert to another
database in the future. Again, I'm not talking about
enterprise applications here.

It also seems to me that if all apps used a middle layer,
there would be little reason to choose Postgres over,
say, MySQL.

I'm interested in your comments.

Ed