Is having functionality in DB a road block to scalability?

Posted by Estefany Velez on Programmers See other posts from Programmers or by Estefany Velez
Published on 2012-09-28T10:37:34Z Indexed on 2012/09/28 15:50 UTC
Read the original article Hit count: 267

I may not be able to give the right title to the question. But here it is,

We are developing financial portal for wealth management. We are expecting over 10000 clients to use the application. The portal calculates various performance analytics based on the the technical analysis of the stock market.

We developed lot of the functionality through Stored procedures, user defined functions, triggers etc. through Database. We thought we can gain huge performance boost doing stuff directly in database than through C# code. And we actually did get a huge performance boost.

When I tried to brag about the achievement to our CTO, he counter questioned my decision of having functionality implemented in database rather than code. According to him such applications suffer scalability problems. In his words "These days things are kept in memory/cache. Clustered data is hard to manage over time. Facebook, Google have nothing in database. It is the era of thin servers and thick clients. DB is used only to store plain data and functionality should be completely decoupled from the database."

Can you guys please give me some suggestions as to whether what he says is right. How to go about architect such an application?

© Programmers or respective owner

Related posts about architecture

Related posts about database