0.00

ORM: slow, inefficient and a real bad approach for medium or large web projects

Image
The Object Relational Mapping (ORM) approach for developing web projects is good just for small projects. Once your project will grow to a medium size one you will hit serious performance issues. If your project will grow to a large one will become almost unusable. And ORM is not an eco-friendly / green technology, it highers the carbon footprint by increasing the required computing power usage in all web projects.

Green Software Foundation Logo
"Build a trusted ecosystem of people, standards, tooling and best practices for creating and building green software."
Change the culture of building software across the tech industry, so sustainability becomes a core priority to software teams, just as important as performance, security, cost and accessibility. Reduce the total change in global carbon emissions associated with software. When evaluating choices to choose the option that advocates for abatement (reducing emissions) not neutralisation (offsetting emissions).


An overview of what ORM (Object Relational Mapping) is

"ORM is not a green software pattern, because it is increasing a lot the hadware resources usage thus the carbon footprint."
The Object Relational Mapping (ORM) is "a technique for converting data between a relational database and the heap of an object-oriented programming language".
Shortly, instead working with a DBAL query like approach the developers using ORM will use an object style approach. That will generate a lot of extra classes to be parsed, will increase code complexity, will slower down the application, will increase CPU and memory usage. That is ORM. Old and bad coding pattern.

ORM for a web project

All good until now. Sounds very cool.
Why developers to learn SQL ? Not necessary ...
Have advantages of keeping easy "database migrations", great ! Actually a DBAL can also manage database "migrations" instead of ORM.
Does the ORM impact the overall performance ? Yes ! And sometime thay may have security flaws ...
How Much ? ... it depends on the project size thus:
  • for a small project with few database tables (10-50), there will be a drop in performance of 50% - 150% (up to 2.5x slower)
  • for a medium project, with a medium database structure (50-100 tables), the drop in performance can be 250% - 1000% (up to 10x slower)
  • for a large project, with a large database structure (150+ tables), the drop in performance can be 2000% - 10000% (up to 100x slower)
What the above metrics mean ?
Well, the above metrics were measured in a lot of projects over time, mostly using PHP or NodeJS using MariaDB/MySQL or PostgreSQL. There are gaps in the above metrics because once a project becomes medium or large not only the database structure and the number of ORM classes is increasing but also the number of SQL operations is increasing a bit, not so much but matters.
If you want a deeper technical explanation, see these links:

Let's not forget that it is a web project, not an intranet or a desktop application ! For a desktop or intranet application, just go with ORM whatever... the response time really doesn't matter. What is considered a reasonable response time for a web application ? This may differ if that is an API or a full featured web project.
To easy the explanations, we'll consider a web API. For a web API, the widest accepted answer is:
"Generally, APIs that are considered high-performing have an average response time between 0.01 seconds and 0.25 seconds per request".
Well, some say 1 second is still a good response time for an API. But only for small projects. Medium projects with so high API response time may easily enter DDOS and large APIs will become unresponsive because the number of concurrent users over time may vary too much so the edge moments can ask for serving 500x more requests than almost idle moments.
The most deep technical details on these you will find reading the above article written under the advisory of "Mikael Svahnberg", Faculty of Computing, Blekinge Institute of Technology, Sweden. There are many other links and articles ... but finally in 15+ years of developing web projects all the concerns does confirm !
Is the ORM that bad ? Yes, honestly. For the performance, for keeping developers mostly far away of database, for the future of your project and not eco friendly.
Parsing a lot of ORM extra classes in PHP / NodeJs or whatever programming language you use is a totally disaster for a web project. The hardware cost will go mad. And if you go with AWS or virtual clusters / containers cost will go double mad. The lowest execution speed a core have the more slowness impact you will notice.

Raw SQL Queries ? Are they appropriate for a web project ?

NO ! The SQL Injection risk is too high !
Then what !? What's the alternative approach ?
A good advice, use a DBAL such as Doctrine DBAL or LaminasDB (PHP) or similar ; or nodetrine-dbal (NodeJs) ; or other DBAL (for other languages), there are a lot of options.
What's the difference betwen Raw SQL Queries or a DBAL like approach ? The most notable, you must not deal directly with escaping SQL input variables, so the risk of doing a mistake with an unescaped SQL variable will be zero. But also look at the below examples. The code looks actually better than using any ORM. Is still safe, much faster, more appropriate for QA and code review:

// PHP, LaminasDB (DBAL)
use Laminas\Db\Sql\Sql;

$sql    = new Sql($adapter, 'foo');
$select = $sql->select();
$select->where(['id' => 2]); // $select already has from('foo') applied


// PHP, Doctrine DBAL
// You can access the QueryBuilder by calling Doctrine\DBAL\Connection#createQueryBuilder

$conn = DriverManager::getConnection([/*..*/]);
$queryBuilder = $conn->createQueryBuilder();
$queryBuilder
    ->select('id', 'name')
    ->from('users')
    ->where('email = ?')
    ->setParameter(0, $userInputEmail)
;


// NodeJS (javascript), nodetrine-dbal

let connection = DriverManager.getConnection([/*..*/]);
let queryBuilder = connection.createQueryBuilder();

queryBuilder
    .select('id', 'name')
    .from('users')
    .where('email = ?')
    .setParameter(0, userInputEmail);


Then why so many development teams use ORM ?

Simply: Because by example, some of the most popular frameworks such as Laravel (Eloquent ORM) and Symfony (Doctrine ORM) are promoting this style of coding.
Is that bad ? Of course. Event the PHP coding standard they are promoting is wrong.
Arguments ? Plenty ...
A simple example:

// PSR coding standards (Symfony wants)

namespace Acme;

use Other\Qux;

/**
 * Coding standards demonstration.
 */
class FooBar
{

    /**
     * @param $dummy some argument description
     */
    public function __construct(string $dummy, Qux $qux)
    {
        $this->fooBar = $this->transformText($dummy);
        $this->qux = $qux;
    }

    /**
     * @deprecated
     */
    public function someMethod(int $id): string
    {
        return Baz::someMethod($id);
    }

    /**
     * Performs some basic operations for a given value.
     */
    private function performOperations(mixed $value = null, bool $theSwitch = false)
    {
        if (!$theSwitch) {
            return;
        }

        $this->qux->doFoo($value);
        $this->qux->doBar($value);
    }

}

Expecting many questions like "How can you say that ? Symfony is a great framework ..."
Yes, both: Symfony and also Laravel are great frameworks. But not 100%. Some things are wrong there. Mostly they promote the ORM instead of DBAL. Second, the code standard imposed by them is at least wrong for one point. Arguments ? Yes. Google code standards, in Go Lang ! Much logic, much trusted. Why talking about the code standards and ORM ? Code standards are not covered by this article but it is just another example of some bad practices. What this mean ? Look at the Go lang code sample below. This will compile. Notice the "{" is on the same line as the method definition ! Not Under ! Trusting Goole coding standards or PSR is your choice. Whatever ...

// Go lang sample code: OK, code will compile

package main

import (
	"log"
)

// the "{" is on the same line as the method definition, mandatory !
func main() {

    log.Println("Helo World ...")

}

Using the "{" on the next line under the method definition, the Go Lang code will fail to compile. Why ? Because Google says this is a wrong coding standard ! Simply that.

// Go lang sample code: WRONG, code will NOT compile

package main

import (
	"log"
)

// the "{" is on the next line after the method definition, wrong, code does not compile, will raise a compilation error !
// ERROR: test.go: syntax error: unexpected semicolon or newline before {
func main()
{

    log.Println("Helo World ...")

}


Conclusions

Stay away of ORM as much as you can in all your projects. Think your software patterns to be green software, eco friendly.
And if you prefer to open the bracket on the same line as the method definition is actually better (as Google says and is mandatory in Go Lang). Never take 100% from a framework or another. It is a free world outside there, a lot of other interesting vendor like PHP components you can use even with any framework you like.
Same apply to NodeJS (many actual NodeJS developers come from a PHP background ... still, thus the same style you'll see too).
And if you need a better reason to drop ORM than your project response time and the hardware cost, consider this:
Going with a green planet means lowering as much as you can the carbon footprint, also in development, starting with reducing your hardware usage and CPU intensive web projects. Dropping ORM will lower drastically your hardware carbon footprint ! It's a start.
It would be incomplete to use your bicycle for travel to your developer job to be eco-friendly, and go for your job where your old-style managers insist "you need to go with ORM" making the project so slow, using 3x-10x more hardware resources which will higher up the carbon footprint a lot.
You can really start this by measuring your web project response time, performance, resources usage with ORM and without it. You'll notice the difference !