Yesterday I asked myself if the database is part of the back-end. On the one hand the back-end includes everything the user doesn't come in contact with, if you look at it that way the database clearly belongs to the back-end.

But I personally can't really get used to it because there is no business logic in the database. I would rather reference the classic 3-layer architecture (Presentation: Front-End, Logic: Back-End, Data: Database).

  • 7
    How you cut the pie and how you name the slices is mostly a matter of taste. Of course, when designing systems, naming is part of the communication process, so you should rather ask who you're communicating with and what your common language is. Sep 15, 2020 at 5:29
  • 1
    Frontend means the exposed, outwards facing part of a system or sub-system, while backend is everything behind this - not just business logic, but everything hidden behind the frontend. What actually is the frontend depend on which sub-system you are considering. But by your terminolgy, the "back end" logic would actually be the "front end" to the database, so that is IMHO just confusing. Naming of layes is just tools for communication, so don't make it unnecessary confusing.
    – JacquesB
    Sep 15, 2020 at 10:43
  • I am working here with a system where we call "UI & database" the "front end", and a "simulation/calculation engine" which processes the data from the front end is called "back end". All a matter of perspective.
    – Doc Brown
    Sep 15, 2020 at 14:47
  • The database is a detail. Lots of front ends (e.g. mobile apps) have databases (they need to store some stuff for themselves, e.g. offline e-mails, cached content, etc.). Lots of back-ends have databases. Some are stateless, and don't.
    – Alexander
    Sep 15, 2020 at 20:38

5 Answers 5


Depends on who you ask

From the perspective of a frontend developer, the answer is generally yes. Since the business logic acts as a (shielding) middle man between the FE and any possible data store, the FE is therefore unable to knowingly separate one from the other, and thus "the backend" refers to that (to the FE developer) inseparable blob.

But to a backend developer, the answer is generally no. Backend devs are (and need to be) very aware of what belongs in their codebase and what doesn't, so the distinction between the two is clear. When a BE dev speaks about "the backend", they tend to mean "my codebase", not the database.

Just as the BE is a remote resource for the FE developer, the database is a remote resource for the BE developer. Just like how FE developers think of the backend as something outside of their own scope, so do BE developers think about the database.

That being said, there are no absolutes here. A BE developer may be speaking to a FE developer using that FE developer's terminology, or a full stack developer may contextually include/exclude the database from "the backend" based on the current conversation, or...

But I personally can't really get used to it because there is no business logic in the database.

As much as I don't like using them, stored procedures are a form of business logic. That is precisely why I don't like having them around in the database, since I don't want to have their business logic in the database. But that doesn't mean some projects don't make use of them.

I would rather reference the classic 3-layer architecture (Presentation: Front-End, Logic: Back-End, Data: Database).

Your statement implies that "the backend" and "the business logic" are direct synonyms. They are most certainly not. The backend includes business logic, but it tends to contain a lot more than just business logic, even if you ignore the database itself.

That being said, the business logic is the main purpose of the backend. Therefore, if you were to conflate the two in an informal conversation, people will generally be able to infer and understand what you mean.

But if you're going to ask a question on precise definitions and what exactly is contained in each definition, then you shouldn't be conflating "the backend" and "the business logic" either.

Your assertion that "the database" and "the business logic" are discrete components is quite correct - assuming no stored procedures, which seems to be the governing consensus nowadays.

But your assertion does not apply to "the backend", as that is a loosely defined concept whose exact definition depends on who uses it and in what context they do so.


The term backend isn’t as clearly defined as you might think.

If you consider the frontend as ‘everything the user can see and interact with’ and the backend as ‘everything else’, then the database belongs to the backend part of a system. This definition isn’t very satisfactory. Think about the file system, the operating system, the hardware and network; are all of these part of the backend?

Many developers consider the backend part of a software system to be responsible for providing data access and manipulation services for the frontend. The code under their control that provides these services defines the boundaries around the ‘backend’. The database itself is not under control of a developer, but the code that generates the tables is.


Yes, because it resides on the same machine as the server or has a privileged network access to the database server machine. This is different than the firewalled access that the user (front end) gets.

  • Some frontends have privileged network access to their backends. Does that mean the frontend therefore includes the backend? Why would that separation be different for backend/database than for frontend/backend?
    – Flater
    Sep 15, 2020 at 9:23
  • I think you are being pedantic. The point is that the front end communicates using different network protocols. Certainly during development where everything is on your local box you could say the frontend includes the backend. You still use different connection API's to talk to the DB from the server process than you use to talk to the browser. Sep 15, 2020 at 15:57

Not a wonder that you’re puzzled with all these ambiguous and loosely related terms! You may therefore call it as suits the need, but better provide your definition of what you really mean:

Front-end vs. backend is a subdivision that is primarily about the user-perspective:

  • The front-end is what the users see and interacts with.
  • The back-end is what the user doesn’t see but matters behind the scene.

These terms may perfectly be used for a nice GUI interface to hide a complex command-line software on the same machine.

The term is now routinely used in a web context to as a synonym for client-server, which is a distribution model. In this context front-end means the part of the software that runs on the client in interaction with the user, and backend everything that runs on the server(s). It is highly ambiguous on this understanding where to place HTML generation on the server part if the team in charge is not the front-end team.

Layered architecture models are a more detailed subdivision of theses concerns. But it can be used in different ways as well:

  • It can be about the internal organistaion of the source code and dependencies (e.g. presentation/business logic/data access - the database server is out of the picture)
  • It may also be about independent components that can be distributed on several computers (e.g. presentation/application service(s)/database-server(s), the data-access logic running as part of the application services

Finally, to make it even more ambiguous, layered architectures are far from being the only model, and nowadays you find concentric models with domain logic in their core, business and application logic surrounding it, and and adapter layer around allowing to connect the whole service to other services. So yet another subdivision with overlapping terms ;-)

  • Yes, database infrastructure is part of the backend. It is considered so in N-tier, N-layer and client server. In MVC the user interacts with the view, and the controller interacts with the model (business logic and DAO) and the model interacts with the database, and frontend is usually considered to be the part the final user interacts with (the view and the client app) even if the view is dynamically generated in the server.

  • Sometimes there are business logic in the database (stored procedures). But let's suppose the is no business logic on the database, there are many components that are part of the backend and are business-logic-agnostic and that cannot be called "frontend" because of that.

  • There are some scenarios where one could argue whether or not database is part of the backend but one could safely say, and be right almost all the time, that the dadatabases are part of the backend, not the frontend in most applications.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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