I'm a student of systems engineering, and all my teachers and friends (that actually work in the area) say that it is better to have as much logic as possible implemented in the database (queries, views, triggers, T-SQL, etc.). I think that it's better to have it in the code.

Their reasons are:

  • If they need to change the language, almost all logic will be in the database; therefore the time of implementation will be minimal.

  • Changes in the language are more common than in the database.

My reasons are:

  • It is obvious (in the current environment of my country at least) that they do not change the language of the projects that "easily." (I've seen programs that are still in FoxPro, because if it works, there is no need to change it).

  • Programming languages are about functionality, while databases are about data. You can have programming functionality in databases, but I think that it should be limited to the components that affect data.

  • It is easier to implement new requirements (for example: If the customer wants an API).

  • Normally when they use logic in the database, the rest of the logic that is implemented in the code is more spaghetti-like (random functions, for example).

  • Generally, it is more usual to have more programmers than database administrators (DBAs).

    Which implementation is the best?

  • 13
    Business logic should not be in the database. Simple as that. If you put it there, you can't easily test it, you are coupled with the database engine, and you'll have hard time caching stuff, because even when you cache it, you will still be forced to hit the database server no matter how good your caching mechanisms are. It used to be common putting BL in the database, it's not recommended today.
    – Andy
    Commented Apr 1, 2016 at 17:12
  • Programmers working on an application connected to a database will have to know SQL, even if they are using making all database access through an ORM. Commented Apr 1, 2016 at 17:31
  • 2
    There's no actual question asked here... Commented Apr 1, 2016 at 17:34
  • @GrandmasterB Thanks for point me , it seems that I deleted it. Commented Apr 1, 2016 at 19:55
  • 1
    @gnat Yes, you are right. Actually it seems that in my rush I closed it when I was looking for the alternatives, as a junior dev (still studying and with just 3 months of programming experience in a real work) . I often find myself afraid to publish a question here, because ... well nobody wants to feel dumb. However I improved a lot (taking in account my way of thinking 2 years ago) thanks to that and seeing my lack of experience. I don't regret publishing this question because the answers of btilly and MichaelShaw gave me a more human perspective than the alternative question. Commented Apr 1, 2016 at 20:04

6 Answers 6


See How much business logic should the database implement? for previous discussion.

In general, everyone wants things done in the layer they control. Because then they control it.

Every database vendor wants people to put as much logic into the database as possible. Because that locks you into the database. The reasoning is that if multiple applications use the same database, they will reuse code.

However programmers emphatically disagree. Databases offer poor programming options. Deploying code to databases is hard. Databases lack basic tools for revision control, interactive editing, deployment and unit testing. Stored procedures tend to involve horrible to debug action at a distance. It has become less common to have multiple applications hit the same database. And if you ever have to make something scale, the one bottleneck that is hardest to fix is your database.

My bias is clear. I'm a programmer.

But I've been programming for close to 20 years, mostly as a back end programmer who is responsible for data. I've seen the argument many times for moving logic into the database. I've seen systems that did it, and systems which avoided it. I've had to migrate databases, migrate code bases, etc, etc, etc.

The worst messes have always been when business logic was in the database. They were always the hardest ones to fix. And I can say that while I've many times encountered the claim that "we moved logic into the database for performance", performance is almost always better with a clean normalized data model, good indexes, a caching layer in front of the database, and sane algorithms implemented in a modern programming language.

  • What really surprise me is that my friends are programmers (who sometimes needs to use sql) and they tend to prefer the database way. Commented Apr 1, 2016 at 20:08
  • The very worst I've seen was when the business logic was in the database without actually using procedural SQL - just a bunch of tables to declaratively define the business logic. Making your own pseudo-language in the database is one of those "this will be so cool" ideas that just completely miss the point of having a programming language in the first place. And now you have a horrible mess in the database procedures, the database schema and tables and your back-end code. Ouch.
    – Luaan
    Commented Apr 1, 2016 at 22:43
  • @Luaan I always ask that questions to my peers, if they should put all login in db and just use programming to display data, why is called programming? Commented Apr 1, 2016 at 22:59
  • 2
    @LarizzaTueros It is very easy for programmers to repeat "best practices" without thinking through why those practices would be best.
    – btilly
    Commented Apr 1, 2016 at 23:38
  • Many years later, I would like to make a point about that "almost always" in my comment. If you're interacting with a lot of external things, like a website does, it is hard for moving logic into the database. If you're manipulating significant datasets, it is easy for moving the logic to your data to be a win. I'm currently working with a lot of timeseries, and with lots of logic in the database for that reason. It is still hard to get right, but it is at least a sensible decision.
    – btilly
    Commented Dec 31, 2020 at 0:24

I am very firmly of the view that when ever possible, business logic should be kept in the software layer and not the database layer. Note, that when ever possible falls far short of always.

There are strong arguments for both ways, and as always use engineering good judgement to decide for each project how much weight should be applied to each point before deciding which is the more appropriate choice.

(as other people make sugestions in the comments, they can be added to the list)

Arguments for the database handling business logic:

  • Business logic needs data to operate on. Getting the logic processing as close to the data gives better performance
  • One place to apply updates

Arguments for the software layers handling business logic:

  • Well written software is typically much easier to understand, debug and maintain than SQL stored procedures.
  • Application Servers can scale out as well as scale up if the internet application becomes popular.

As a seasoned professional developer, needing a quick fix to improve application latency, the choice can be between moving some slow running business logic into a stored procedure on the database and/or to implement caching of slow processes.

There is however a serious gotcha with database based business logic. If your application needs to scale massively, always prefer systems / processes that can scale out (by this I mean, you can add more servers into the processing pool). SQL Databases can only scale up (you need to find a more powerful server to replace your existing one.) If your application has lots of database business logic, you will reach this problem earlier.

  • +1 for pointing out that because the database doesn't scale, putting all the logic in the DB is actually the cause of a lot of performance issues. Another issue I see is that certain things that are really simple and fast in most programming languages are surprisingly complex in a database. My experience tells me to keep SQL simple and do complex transformations elsewhere.
    – JimmyJames
    Commented Apr 1, 2016 at 21:21
  • Would you care to elaborate on "One place to apply updates"? In my experience, it's the exact opposite - it makes updating anything a huge pain, and it will break constantly. Unless you're always deploying directly to production, which is even worse.
    – Luaan
    Commented Apr 1, 2016 at 22:45
  • Im not saying this is "best practice", its not. However a common set up, two servers behind a load balancer, with a separate database, you can often hot update by running the SQL script to update the stored procedures during a quieter period. If its a code deployment, the servers have to be rotated out of the load balancer, IIS site deployed, server warmed up, and then reintroduced back to the load balancer. Commented Apr 1, 2016 at 22:52
  • @MichaelShaw you can do hot code reload in many platforms, not just in databases. Java applications servers like Tomcat can simply reload the changed classes without restarting the application: mulesoft.com/tcat/tomcat-reload Commented Apr 2, 2016 at 9:53
  • Yeah, I appreciate that, however, you will still need to do this, per server, and not just once on the database. At the end of the day, engineering is balancing competing demands to obtain the best overall outcome. Commented Apr 2, 2016 at 10:54

Two very important points are missing in your pro-database arguments:

  • performance: database code is executed with direct access to the data, thus avoiding unnecessary transfers (be it across fetching API and mapping schemes on the same machine, or across network for client/server communication)
  • consistency: as several applications may access/update the same database, encapsulating consistency and business rules centrally therein, ensures that they will be reliably enforced.

But some very important points are also missing on your contra-database arguments:

  • scalability: the more you put on the database, the more this component will become a bottleneck. Of course you can take bigger servers and add CPUs, but sooner or later you'll meet the physical limits.

  • vendor lock-in: SQL is very standardized, but the languages for triggers and procedures are rather diversified and often proprietary: T-SQL for Microsoft, PL/SQL for Oracle, any language for DB2. Developping on the database locks you in for a vendor, and doesn't allow you to make benefit of increased competition, or migrate to new operating environments.

  • legacy architecture: overcentralisation of data and processing on huge servers... Doesn't this bring us back in the era of mainframes ? This seems obsolete nowadays,when new major architectural trends emerge aiming at maximal scalability: flexible NoSQL databases of different types ideally suited for object oriented development, microservices with every microservice having its own database, and bigdata architecture such as lambda architectures where all the processing pipelines are outside the database.

  • obsolete arguments: the time of error prone redundant cobol code copied across applications is over. What could only be reliably encapsulated in an RDBMS yesterday, can very well be encapsulated in modern software architectures, using maintenable and reusable object oriented components, libraries, and version control systems.

To summarize:

  • yes, there are valid arguments for putting the maximum of logic on the database side. But these arguments do however no longer meet new needs and constraints of the internet scale, the technological shift, and the emergence of bigdata.
  • no, I don't think there is a universal best approach. The most suitable approach shall be choosen by a software architect, case by case, based on the concrete requirements and needs.
  • Thanks for expanding the arguments, I have seen performance oft be cited notably. It's important to realize that performance with data access is often linked to (1) the amount of data accessed and (2) the amount of data transferred. In the OLTP world, at least, I've rarely needed more than a well-crafted SQL query (sometimes with a few with a temporary table) to achieve my goals in an efficient way. Commented Apr 2, 2016 at 16:08
  • 1
    @MatthieuM Of course no issue if you have a nice server and a low number of users (compared to the server's capacity). But it's a question of scale: in the client side approach (1) crafting a SQL statement is done on the client side, (2) if you have 40000 users all the unnecessary bi-directional traffic will introduce network load and latency (3) this end-to-end latency will be propagated to concurrent transactions via locks set for transactional consistency, especially if you have frequently used data (e.g.stock level of popular products, counters for order numbering, etc...).
    – Christophe
    Commented Apr 3, 2016 at 9:22
  • I didn't say it's an absolute criteria, but it shouldn't be ignored, especially if the system has to be scalable to a higher level.
    – Christophe
    Commented Apr 3, 2016 at 9:44
  • Interesting, in the applications I worked on scaling was achieved by delegating more to the client, in order to save CPU on the database server (then again, we use Oracle so the license cost is based on the number of CPUs...) Commented Apr 3, 2016 at 10:55
  • @Matthieu that sounds like the start of the database capacity problem. Imagine what happens if the traffic increases 10x? what about 100x or 1000x - this is the scaling problem that databases have. Commented Apr 4, 2016 at 7:32

Besides all the facts that have been already pointed out, also remember that having business logic in your code rather that the database eventually turns out to be cheaper.

When looking for a developer for an application written in PHP and using MySQL as a database, should your business logic be stored in the database, a simple PHP programmer is not enough, and you will have to find someone who also knows how to write, debug and optimize stored procedures. Suddenly you need a guy who knows not only one thing, PHP, but two, PHP and MySQL programming.

And do not even think about moving to a higher-performance engine like PostgreSQL, then you also need to hire a guy to transform all stored procedures to PL/SQL.

When having business logic in the code, this is only a matter of writing a new abstraction layer for PostgreSQL and swapping out the dependencies in your application, boom, your application suddenly knows PostgreSQL.

  • Eh, this works in reverse, put all your business logic in your app, a simple PHP programmer isn't enough, you need someone who knows how to deal with applications containing complex business logic.
    – Kyle Hale
    Commented Apr 3, 2016 at 4:17
  • @KyleHale When the application is well written and you hire a <language x> developer (who knows the <language x> at least a little bit), it is going to be much easier for him to understand complex things in the language he was hired to program in, rather than a completely different one.
    – Andy
    Commented Apr 7, 2016 at 15:39
  • So similarly you could hire a good database programmer and put the logic in there? I just don't think it's a very compelling argument. And I say that as a DB guy who would much prefer the logic to be in the app/service layer.
    – Kyle Hale
    Commented Apr 8, 2016 at 2:47
  • "When the database is well written and you hire a SQL developer (who knows SQL at least a little bit) it is going to be much easier for him to understand the complex things in SQL." What you probably mean to say is there are more good application programmers than good SQL developers in the general population, which is true.
    – Kyle Hale
    Commented Apr 8, 2016 at 2:49

Previous answers give great reasons to why it's easier/better to put logic in application code vs in a database. One exception I'd like to highlight is when using a big data database/tech stack. In this case, many of the disadvantages go away:

  • You can write unit tests since it's actual code you wrote that sits in the database.
  • You can debug, albeit through unit tests.
  • You have version control, since it's code.

And the advantages of having logic in the database become way more important:

  • Depending on the amount of data being processes, it might be unreasonable to ship data to your application code.
  • Scaling - your code scales same as the database scales - in many cases, performance and storage are linear in the number of nodes (machines).

Great question - this is something I advocate at the office very regularly.

My view is that most of the logic should be in code. It's always very tempting to use a variety of languages because they each have their strengths, but unless you have a perfect development setup (which is very rare), it's preferable to stick to one language.

People have mentionned unit testing / revision control versionning, but a very important thing is deployment. Having to synchronize database code changes with code changes can be hazardous.

If you're in a large-scale software development company, you may have enough specialized people who know either side (database programming vs coding), but otherwise it's tricky to find people who can juggle between the 2 worlds (and most importantly, who make the right trade offs when it comes to deciding what part of the logic needs to be in what language).

Personally, I find SQL programming languages very primitive, and development tools for them even worse. So I would favor modern programming languages. A good ORM can save most developers from knowing anything about the database, and is worth investing into. People mentionned the efficiency of doing things server side, and this should not be abandoned. There are some very nice programming patterns that allow to express server-side operations using what appears to be a client-side API (e.g. IQueryable in C#).

In practice, I am still using the odd views or stored procedures, but they are usually mostly purely for aggregation, and have no 'business' logic in them. This is quite useful as they can be used as sources for excel pivottables for instance.

Not the answer you're looking for? Browse other questions tagged or ask your own question.