DEV Community: Mr. S Gupta

How Express Actually Talks to a Database: From HTTP Request to SQL Query

Mr. S Gupta — Sun, 30 Aug 2026 14:04:25 +0000

When beginners start learning backend development, they usually pick up things one at a time and separately, Express routes here, controllers there, middleware somewhere else, then databases, then Prisma, then authentication. Each piece makes sense on its own.

But one question tends to linger even after all that. When a user clicks something on a website, what's actually happening behind the scenes, step by step?

Say someone opens an e-commerce site and clicks "Show my orders." What happens right after that click? Does Express talk to the database directly? Does Prisma just handle everything on its own? Where exactly does authentication slot in, and where does the actual SQL query get executed? Once this full flow actually clicks, backend development stops feeling like a pile of disconnected pieces.

The big picture

A modern backend app generally looks something like this.

Frontend Application
        |
        v
HTTP Request
        |
        v
Express Server
        |
        v
Routes
        |
        v
Controllers
        |
        v
Services
        |
        v
Database Layer
        |
        v
PostgreSQL Database

Each layer here has its own job, so let's walk through them one at a time.

The user sends a request. Say someone clicks "View Profile." The frontend fires off an HTTP request, something like GET /api/profile, carrying a method, a URL, maybe an authorization header, and sometimes a body. The browser genuinely has no idea your database even exists, it only ever talks to your backend API.

The request reaches the Express server, which is just sitting there running somewhere, waiting.

import express from "express";

const app = express();

app.listen(3000, () => {
  console.log("Server running");
});

The moment that GET /api/profile request arrives, Express picks it up.

The router figures out where it goes. A real app has dozens of endpoints, /api/users, /api/products, /api/orders, /api/payments, and the router's whole job is deciding which piece of code handles which one.

router.get("/profile", getProfile);

In plain terms, if someone hits GET /profile, run the getProfile function.

Middleware runs before the controller ever sees the request. Think of it as a checkpoint the request has to pass through first.

Request
   ↓
Authentication Middleware
   ↓
Validation Middleware
   ↓
Controller

Say a request comes in with Authorization: Bearer token123. The middleware's job is simply asking, is this token actually valid?

function authMiddleware(req, res, next) {
  const token = req.headers.authorization;

  if (!token) {
    return res.status(401).json({
      message: "Unauthorized"
    });
  }

  next();
}

If everything checks out, next() runs and the request keeps moving forward.

The controller takes over.

async function getProfile(req, res) {
  const userId = req.user.id;

  const profile = await userService.getProfile(userId);

  res.json(profile);
}

A controller's real job is just taking the request, pulling out what it needs, calling whatever service handles the actual work, and sending back a response. It really shouldn't be carrying heavy database logic itself.

The service layer handles the actual business logic.

async function getProfile(userId) {
  const user = await prisma.user.findUnique({
    where: { id: userId }
  });

  return user;
}

This is where the real database call happens.

Prisma steps in here. When your code calls prisma.user.findUnique(), Prisma quietly builds the actual SQL behind it, something like SELECT * FROM users WHERE id = 1;, and PostgreSQL runs it.

Service
   ↓
Prisma
   ↓
SQL Query
   ↓
PostgreSQL
   ↓
Result

The database sends data back, something like { "id": 1, "name": "Rahul", "email": "rahul@test.com" }, and it travels all the way back up through Prisma, the service, the controller, the Express response, and finally lands back at the frontend.

Put the whole thing together and you get this complete picture, from the click all the way to the UI updating.

User Clicks Button
        |
Frontend Sends HTTP Request
        |
Express Server
        |
Router
        |
Middleware
        |
Controller
        |
Service
        |
Prisma / Drizzle / SQL
        |
PostgreSQL
        |
Response Returns
        |
Frontend Updates UI

A question that comes up a lot at this point is, why not just call the database straight from the controller? Technically, you absolutely can.

app.get("/users", async (req, res) => {
  const users = await prisma.user.findMany();
  res.json(users);
});

That'll work fine for a small project. The trouble shows up once the app grows, controllers stacked directly on the database without any layers in between tend to balloon in size, logic gets duplicated all over the place, testing becomes a pain, and maintaining any of it gets genuinely difficult over time. With proper layering, routes to controllers to services to a dedicated database layer, code stays organized, testing gets easier, teams can actually work in parallel without stepping on each other, and future changes stay contained instead of rippling everywhere.

Where does all this code actually live

Knowing the flow is one thing, but figuring out where this code should actually sit inside a real project is the next question worth answering.

Beginners typically start with something dead simple.

src
├── index.ts
├── routes.ts
└── database.ts

That's genuinely fine for a small project. But as users pile up, products get added, payments show up, authentication gets bolted on, keeping everything crammed into a couple of files stops being manageable.

A more production style layout tends to look like this.

src
├── index.ts
├── app.ts
├── config
│   └── env.ts
├── routes
│   ├── user.routes.ts
│   └── product.routes.ts
├── controllers
│   ├── user.controller.ts
│   └── product.controller.ts
├── services
│   ├── user.service.ts
│   └── product.service.ts
├── repositories
│   ├── user.repository.ts
│   └── product.repository.ts
├── db
│   └── prisma.ts
├── middleware
│   ├── auth.ts
│   └── error.ts
├── validators
└── utils

Every folder here is pulling its own weight. index.ts is really just the entry point, its only job is starting the server, nothing more.

import app from "./app";

app.listen(3000, () => {
  console.log("Server running");
});

app.ts is where the Express app actually gets configured, middleware loaded, routes wired up.

import express from "express";
import userRoutes from "./routes/user.routes";

const app = express();

app.use(express.json());

app.use("/api/users", userRoutes);

export default app;

The routes layer's whole job is deciding which URL goes to which controller, nothing about the database belongs here.

router.get("/profile", getProfile);

The controller layer handles request and response, pulling data out and handing it off.

export async function getProfile(req, res) {
  const user = await userService.getProfile(req.user.id);
  res.json(user);
}

The service layer is where the actual business logic lives, deciding what needs to happen, in what order, and under what rules.

export async function getProfile(userId: number) {
  const user = await userRepository.findById(userId);
  return user;
}

The repository layer is what talks directly to the database.

export async function findById(id: number) {
  return prisma.user.findUnique({
    where: { id }
  });
}

Here's the real payoff of splitting things this way. If Prisma ever got swapped out for Drizzle down the line, only the repository layer would need to change, the service code sitting above it wouldn't need to know or care. That's really the whole point of the repository pattern.

And the database layer itself is usually just one shared client instance.

import { PrismaClient } from "@prisma/client";

export const prisma = new PrismaClient();

It's worth flagging why this matters, because beginners sometimes create a fresh Prisma client inside every single request.

app.get("/users", async (req, res) => {
  const prisma = new PrismaClient();
});

That's a genuinely bad habit, since it can spin up way too many database connections and hurt performance badly. Sticking to a single shared instance, sitting on top of a proper connection pool, is the better approach.

Application
   ↓
Single Prisma Client
   ↓
Database Connection Pool
   ↓
PostgreSQL

A login flow is a good example of how all these layers cooperate. A POST /login request moves through the route, into the controller, into an auth service, which hits the database, checks the password, generates a JWT, and finally sends back a response.

const user = await userService.findByEmail(email);

const valid = await bcrypt.compare(password, user.password);

const token = jwt.sign({ id: user.id });

User input should never head straight to the database untouched either. Something like { "name": "", "email": "wrong-email" } needs to pass through a validation layer first, usually something like Zod, Joi, or Yup.

const schema = z.object({
  email: z.string().email(),
});

Errors deserve real handling too, not just a stray console.log(error) buried in a try-catch. A cleaner approach routes errors through dedicated middleware instead.

app.use((error, req, res, next) => {
  res.status(500).json({
    message: "Something went wrong"
  });
});

Put together, the full architecture looks like this.

Client
   ↓
Routes
   ↓
Controllers
   ↓
Services
   ↓
Repositories
   ↓
Prisma / Drizzle
   ↓
PostgreSQL

None of this is mandatory for every project though. A small app can genuinely get by with just routes, controllers, a db folder, and an entry file. Services and repositories are things you layer in as the project actually grows into needing them, not something you're required to bolt on from day one. The real goal here was never piling on more folders for their own sake, it's making sure every piece has a clear, single responsibility. If the database ever needs to change, the whole app shouldn't need rewriting. If auth logic changes, only auth related code should need touching. That's really what a maintainable backend comes down to.

What's actually happening between Express, the ORM, and the database

There's still one layer worth pulling apart properly, what's actually going on inside that database layer. When you write await prisma.user.findMany() or await db.select().from(users), what actually reaches the database? Does Prisma talk to PostgreSQL directly? How does a connection even get established? And what happens when a hundred people hit your API at the same exact moment?

The flow isn't quite as direct as beginners often assume. It's not just Express straight to database, it's really more like this.

Express Application
   ↓
Database Client / ORM
   ↓
Database Driver
   ↓
Database Server

Or more concretely.

Express
   ↓
Prisma Client
   ↓
PostgreSQL Driver
   ↓
PostgreSQL

A database driver is really just the software layer handling the actual back and forth between your app and the database. Connecting Node.js to PostgreSQL usually starts with installing the pg package.

import { Pool } from "pg";

const pool = new Pool({
  connectionString: process.env.DATABASE_URL
});

That driver's job is opening connections, sending queries, and handing results back. Prisma doesn't reinvent PostgreSQL's wire protocol itself, it sits on top of a driver underneath it.

Your Code
   ↓
Prisma
   ↓
Database Driver
   ↓
PostgreSQL

So await prisma.user.findMany() becomes SELECT * FROM users; under the hood, and the driver is what actually carries that query over to the database.

When your app first starts up, the database client gets initialized, though the actual connection usually isn't opened right away, it tends to get established only when it's actually needed, sometimes called a lazy connection.

Server Start
   ↓
Database Client Initialize
   ↓
Connection Available
   ↓
Requests Accept

This is where connection pooling becomes a genuinely important concept. Picture a hundred users hitting your API at once. If every single request tried spinning up a brand new database connection from scratch, the database would get overwhelmed pretty fast. That's exactly what connection pools exist to prevent, a small set of ready-to-go connections sitting in a pool.

Application
   ↓
Connection Pool
[Connection 1] [Connection 2] [Connection 3]
   ↓
PostgreSQL

A request comes in, grabs whatever connection's free, does its work, and hands that connection back to the pool once it's done. Say your pool caps out at 10 connections and 100 users show up at once, the first 10 requests grab connections right away, and everyone else just waits their turn until one frees up.

Development and production databases also tend to look pretty different day to day. Locally you're often just running something like PostgreSQL in a Docker container.

docker run postgres

In production, you're usually looking at a managed PostgreSQL service instead, something like AWS RDS, Neon, Supabase's PostgreSQL offering, or Railway.

And database credentials should never be hardcoded directly into your code.

// don't do this
const db = "postgres://user:password@localhost";

That's both a security risk and a deployment headache waiting to happen. Environment variables are the better home for this.

DATABASE_URL=postgresql://user:password@host/database

const url = process.env.DATABASE_URL;

Tracing a real request end to end makes all of this click. Say a GET /api/users/10 request comes in. Express routes it through router.get("/users/:id", getUser). The controller pulls the id out of the params and calls the service. The service calls the repository. The repository calls prisma.user.findUnique({ where: { id } }), which Prisma turns into SELECT * FROM users WHERE id=10;. PostgreSQL runs that, finds the row, and hands it back. From there it travels back up through Prisma, the repository, the service, the controller, and out through Express to the browser as something like { "id": 10, "name": "Rahul", "email": "rahul@test.com" }.

Validation and authentication both slot in before the database ever gets touched. Registration data gets checked by something like Zod before it's allowed anywhere near the database. Protected routes run through JWT middleware first, and if that token's invalid, the database query simply never executes at all.

None of this is just academic trivia either. If you only ever memorize Prisma syntax or Express routing without understanding this flow, you can absolutely build things that work. But the moment something actually breaks, a slow query, a failing database connection, memory creeping up, a sluggish API response, that's exactly when understanding this architecture actually pays off. Backend development was never really about memorizing syntax. It's about understanding the journey a request takes from start to finish.

Pulling it all together

Putting the entire journey in one place looks like this.

User Request
   ↓
Express Server
   ↓
Route
   ↓
Middleware
   ↓
Controller
   ↓
Service
   ↓
Repository
   ↓
ORM / Database Driver
   ↓
Database
   ↓
Response

Or laid out as a full production style diagram.

                     Client
                       |
                       v
                HTTP Request
                       |
                       v
                Express Server
                       |
                       v
                   Router
                       |
                       v
                Middleware Layer
          (Auth, Validation, Logging)
                       |
                       v
                  Controller
                       |
                       v
                   Service
              (Business Logic)
                       |
                       v
                 Repository
              (Database Logic)
                       |
                       v
            Prisma / Drizzle / SQL
                       |
                       v
                PostgreSQL

A lot of beginners end up wondering whether the API itself is basically the database. It's not, an API is really just a communication layer. The frontend asks for something, GET /api/products say, and the backend decides whether that user's allowed to see it, what data actually needs fetching, what query the database needs, and how the response should be shaped. The API's really just acting as the messenger in between.

And there's a good reason the frontend never talks to the database directly, even though some databases technically allow it. Exposing credentials directly to the frontend is a straightforward security risk, since anyone poking around the client code could grab them. Business rules also need somewhere to live, checking stock availability, verifying payment completion, making sure a user isn't banned, and none of that belongs sitting in the frontend. And directly exposing a production database to the open internet is just asking for trouble. The safer shape is always frontend to backend API to database, never frontend straight to database.

Mistakes that tend to show up along the way

Cramming everything into the controller is a really common one early on, validating users, checking products, calculating prices, updating the database, sending emails, building the response, all crammed into one route handler. It works at first, but that controller balloons into a thousand line mess pretty quickly on a bigger project. Splitting things into controller, service, and repository keeps that from happening.

Scattering database queries across multiple controllers is another one, prisma.user.findMany() showing up in one controller file and again somewhere else entirely. That spreads database logic all over the codebase instead of keeping it contained inside a proper repository layer.

Treating the ORM like it's pure magic is a subtler trap. prisma.user.findMany() looks effortless on the surface, but underneath it's still just running SELECT * FROM users;. If the underlying SQL never actually makes sense to you, diagnosing real performance issues later becomes genuinely hard.

Ignoring proper error handling is another common gap, and in production, things will go wrong eventually, a database going down, bad input, network hiccups, unauthorized access attempts, all of it needs a proper path through central error handling middleware rather than getting quietly swallowed.

And hardcoding secrets directly into code, things like const password = "123456", is a habit worth killing early. Environment variables exist specifically so things like DATABASE_URL, JWT_SECRET, and API_KEY never end up sitting in plain code.

Applications also change shape over time, a users table might start with just id, name, and email, then later pick up a phone number and a created_at timestamp. Migrations exist to track exactly these kinds of structural changes over time, tools like Prisma Migrate, Drizzle Kit, Flyway, or Liquibase are all essentially version control for your database's shape.

Good backends also tend to test layer by layer, controller tests checking whether the response looks right, service tests checking whether the business rules actually hold, repository tests checking whether the database queries themselves behave correctly. And logging matters a lot more once something's actually live, tools like Pino or Winston help capture things like request paths, status codes, and response times so debugging in production isn't a total guessing game. On top of that, keeping an eye on API response times, database performance, error rates, and general server health is just part of running something in production responsibly.

What a solid backend developer actually needs to understand

Realistically, it comes down to a handful of layers stacking on top of each other. HTTP basics, requests, responses, headers, status codes. Express itself, routes, middleware, controllers. The database, SQL, relationships, indexes, transactions. The ORM sitting on top of that, Prisma, Drizzle, migrations. The overall architecture tying it together, services, repositories, proper error handling. And finally, production concerns, deployment, logging, security.

A reasonable learning order tends to look like this: get comfortable with JavaScript or TypeScript fundamentals like async/await, promises, modules, and types. Then pick up HTTP basics, REST conventions, methods, status codes, headers. From there, build actual things with Express, simple APIs, middleware, basic auth. Then move into PostgreSQL properly, tables, relationships, joins, indexes. After that, bring in an ORM, Prisma first, then Drizzle. And finally, round it out with production concerns, Docker, deployment, logging, security.

Honestly, the easiest way to hold all of this in your head is to think of a backend like a restaurant. The frontend user is the customer. The API is the waiter. The business logic is the chef. The database is the kitchen. And the application's rules are basically the recipe everyone's following. A customer never walks straight into the kitchen themselves, there's a whole system standing between them and the food, and a backend works exactly the same way, frontend to API to business logic to database.

At the end of the day, the real skill in backend development was never memorizing one specific framework. Express, Prisma, Drizzle, PostgreSQL, these are all just tools. What actually matters is understanding how a request travels, how data gets stored, where business rules actually belong, how database queries get executed under the hood, and how to keep an architecture maintainable as it grows. Once those ideas are genuinely clear, picking up whatever new backend tool shows up next stops being intimidating, because at that point you're not just learning a tool, you're recognizing a system you already understand.

Prisma vs Drizzle vs Raw SQL: What Every Backend Developer Should Understand Before Choosing an ORM

Mr. S Gupta — Fri, 28 Aug 2026 11:09:05 +0000

When most developers start building backend applications, they're usually focused on one thing, getting an API working. Express routes, controllers, some auth, a bit of middleware, that's usually the whole mental model in the beginning.

But sooner or later, a bigger question shows up. How exactly should your application be talking to the database?

And that's when a bunch of unfamiliar words start floating around. Raw SQL, database drivers, ORMs, Prisma, Drizzle, query builders. Some people will tell you to never touch an ORM and just write SQL yourself. Others will swear Prisma made their life ten times easier. And then there's a smaller crowd that prefers Drizzle specifically because it stays close to SQL instead of hiding it.

So what's actually going on here? Why do all these tools even exist, and how do you know which one to reach for? Let's build this up from the ground.

First, understand how data actually moves

Before Prisma or Drizzle mean anything to you, it helps to see the full picture of how a request travels through a backend app.

Say a user opens your site and clicks something like "show my profile." That click travels roughly like this.

Browser

   |
   v

Express API

   |
   v

Database Layer

   |
   v

PostgreSQL Database

   |
   v

Response back to the user

That "database layer" bit in the middle is where all the confusion tends to live. Your app needs some way to actually talk to PostgreSQL, and there are basically three common ways to do that: writing raw SQL yourself, using an ORM like Prisma, or using a query builder like Drizzle.

Writing raw SQL directly

This is the oldest, most direct route there is, you just write the SQL yourself.

Say you've got a users table.

users

id
name
email
password

Finding a user is as simple as this.

SELECT *
FROM users
WHERE id = 1;

The database speaks SQL natively, so there's no translation happening anywhere.

In Node.js, if you're on PostgreSQL, the pg package is the usual way to send queries like that directly.

import { Pool } from "pg";

const pool = new Pool({
  connectionString: process.env.DATABASE_URL
});

const result = await pool.query(
  "SELECT * FROM users WHERE id = $1",
  [1]
);

console.log(result.rows);

Your code sends SQL, PostgreSQL runs it, and the data comes straight back. Nothing hidden, nothing abstracted away.

Writing SQL yourself gives you complete control, obviously. You can write things like this without fighting any abstraction.

SELECT
users.name,
COUNT(orders.id)
FROM users
JOIN orders
ON users.id = orders.user_id
GROUP BY users.name;

For gnarly reports like that, SQL is genuinely hard to beat. Writing it yourself also forces you to actually understand joins, indexes, execution plans, and performance in general, which is knowledge that pays off no matter what tool you end up using later. And there's no extra layer sitting between your code and the database either.

But raw SQL has real downsides once a project grows past a handful of queries. Imagine a codebase with hundreds of them scattered around.

const result = await pool.query(
`
SELECT *
FROM users
WHERE email=$1
`,
[email]
);

Now imagine someone renames a column somewhere down the line, say email becomes email_address. Every query touching that column is now quietly broken, and the database knows about the change immediately. Your TypeScript code has no idea until something crashes at runtime.

There's a sneakier version of this problem too.

const user = result.rows[0];

console.log(user.emial);

Spot the typo, emial instead of email. JavaScript won't say a word about it. You only find out once that line actually executes and blows up. This exact pain point is basically why ORMs exist in the first place.

So what is an ORM, really

ORM stands for Object Relational Mapping, which sounds fancier than it actually is. All it really means is that there's a bridge sitting between your programming language and your database.

Instead of writing this.

SELECT *
FROM users
WHERE id=1;

You end up writing something closer to this.

user.findUnique({
 id: 1
})

The ORM takes what you wrote and turns it into actual SQL behind the scenes.

Your TypeScript code

        |
        v

ORM

        |
        v

SQL query

        |
        v

Database

Developers reach for ORMs because modern apps need more than just sending queries around. They need type safety, proper migrations, schema management that doesn't require memorizing every table by hand, and honestly, just less repetitive boilerplate. That's the gap ORMs are trying to close.

In the TypeScript world today, the names that come up most are Prisma, Drizzle, TypeORM, and Sequelize. This piece focuses mainly on raw SQL, Prisma, and Drizzle, since those three are what most modern TypeScript backend projects are actually choosing between right now.

Getting into Prisma

Prisma is easily one of the most talked about ORMs in the TypeScript world, and it's usually one of the first names that comes up in any conversation about modern Node.js backends. So what problem is it actually solving?

At its core, Prisma lets your TypeScript app talk to a database using regular TypeScript code instead of SQL scattered everywhere. It supports PostgreSQL, MySQL, SQLite, SQL Server, and MongoDB.

TypeScript code

        |
        v

Prisma Client

        |
        v

SQL queries

        |
        v

Database

You write TypeScript, Prisma turns it into the actual queries.

A typical Express plus Prisma plus PostgreSQL setup ends up looking roughly like this.

Client

  |
  v

Express API

  |
  v

Service Layer

  |
  v

Prisma Client

  |
  v

PostgreSQL Database

Prisma Client is really the piece doing all the work here, it's the actual bridge between your backend code and the database sitting behind it.

Everything starts with a file called schema.prisma, which defines your entire database structure in one place.

model User {
  id       Int    @id @default(autoincrement())
  name     String
  email    String @unique
  password String
}

That's basically saying, create a User table with these four columns, and Prisma understands exactly what that means.

Where raw SQL would need something like this to create the table.

CREATE TABLE users (
 id SERIAL PRIMARY KEY,
 name TEXT,
 email TEXT UNIQUE,
 password TEXT
);

Prisma just needs the schema block shown above, and it handles turning that into actual database changes through something called a migration.

A migration is really just a recorded history of database changes over time. Say your User table starts out simple.

User

id
name
email

Months later you decide to add a phone number field. Instead of manually altering the table yourself, you run something like this.

npx prisma migrate dev --name add_phone_number

Prisma generates a migration file to track that change, something like a folder with 001_initial_setup followed by 002_add_phone_number, so your entire database history stays saved and versioned instead of living only in someone's memory.

Once your schema's defined, Prisma generates a client you actually use in your code.

const user = await prisma.user.findUnique({
  where:{
    id:1
  }
});

Behind the scenes, that quietly becomes this.

SELECT *
FROM users
WHERE id=1;

You never had to type that SQL yourself.

The common operations map over pretty intuitively too. Creating a record that would normally be an INSERT INTO users (name, email) VALUES (...) becomes prisma.user.create({ data: { name, email } }). Fetching all users, which would be a plain SELECT * FROM users, becomes prisma.user.findMany(). Updating a record swaps UPDATE users SET name='Aman' WHERE id=1 for prisma.user.update({ where: { id: 1 }, data: { name: "Aman" } }). And deleting swaps DELETE FROM users WHERE id=1 for prisma.user.delete({ where: { id: 1 } }).

Where Prisma really earns its popularity is type safety. If your schema defines a User with id, name, and email, then writing something like this actually gives you working autocomplete on every field.

const user = await prisma.user.findMany();

user[0].email;

And if you accidentally typo it as user[0].emali, Prisma paired with TypeScript will flag that before your app even runs, which saves a genuinely surprising amount of debugging time down the line.

Real applications almost never have just one table either. Say a user has many posts.

User

id
name

Post

id
title
userId

Prisma represents that relationship directly in the schema.

model User {
 id Int @id @default(autoincrement())

 name String

 posts Post[]
}

model Post {

 id Int @id @default(autoincrement())

 title String

 userId Int

 user User @relation(
 fields:[userId],
 references:[id]
 )

}

And fetching a user along with their posts becomes a single readable call.

const user = await prisma.user.findUnique({
 where:{
  id:1
 },
 include:{
  posts:true
 }
});

Which gives you back something like a user object with a nested posts array, exactly the shape you'd want to work with in your app.

Prisma's biggest strengths really come down to how natural the developer experience feels, how strong the type safety is especially in TypeScript projects, how organized migrations become, how solid the documentation is, and how easily a whole team can look at the schema and immediately understand the database structure.

It's not without trade-offs though. Genuinely complex reporting queries can start feeling awkward compared to just writing raw SQL. Because Prisma hides SQL so effectively, developers who only ever learn Prisma can end up struggling later when they actually need to optimize something at the database level. And there's technically an extra layer sitting in the request flow, application to Prisma to SQL to database, instead of the more direct application to SQL to database path. For most apps that extra layer is a complete non issue, but it's worth knowing it's there.

Prisma tends to make the most sense when you're building APIs in TypeScript, want fast development, mostly need standard CRUD operations, and care a lot about developer experience. A lot of startups and SaaS products lean on it for exactly these reasons.

Where Drizzle fits into the picture

Drizzle is the other ORM that's picked up serious momentum in the TypeScript world, but understanding it really comes down to understanding one thing first, Prisma and Drizzle are built on genuinely different philosophies.

Prisma's whole approach is keeping developers away from database complexity as much as possible. Drizzle takes the opposite stance, keep developers close to SQL, just give them TypeScript's safety on top of it. Both are chasing the same end goal, a better development experience around your database, they just take very different roads to get there.

Drizzle is a lightweight TypeScript ORM that works with PostgreSQL, MySQL, and SQLite, and its whole focus is type safety, performance, staying close to SQL, and keeping the architecture lightweight.

TypeScript code

        |
        v

Drizzle ORM

        |
        v

SQL query

        |
        v

Database

The philosophy difference is easiest to see side by side. Fetching all users in Prisma looks like this, and you never really need to think about what SQL it's generating underneath.

const user = await prisma.user.findMany();

Drizzle asks you to write something noticeably closer to actual SQL.

const users = await db
.select()
.from(usersTable);

You can basically read what's happening at the database level just by looking at the code.

Schemas work differently too. Where Prisma defines things in its own schema.prisma file, Drizzle defines the schema directly in TypeScript.

import {
 pgTable,
 serial,
 varchar
} from "drizzle-orm/pg-core";

export const users = pgTable("users", {

 id: serial("id").primaryKey(),

 name: varchar("name"),

 email: varchar("email")

});

So your database structure literally lives inside your TypeScript codebase, no separate schema language to learn.

The common operations feel like a TypeScript flavored version of SQL itself. Inserting a row that would be INSERT INTO users (name, email) VALUES (...) in SQL becomes db.insert(users).values({ name, email }) in Drizzle. Fetching everything, which is SELECT * FROM users, becomes db.select().from(users). And filtering, which would be SELECT * FROM users WHERE id=1, becomes db.select().from(users).where(eq(users.id, 1)).

People gravitate toward Drizzle for a handful of reasons. It's genuinely lightweight with very little unnecessary abstraction sitting in the way. Because it stays close to SQL, your actual SQL knowledge stays sharp and keeps growing rather than getting hidden behind an abstraction. The queries it generates tend to be predictable since there's less machinery translating your intent. And it was built with modern runtimes in mind too, things like edge environments and serverless setups.

That said, if you've never really learned SQL, Drizzle can feel a lot more confusing upfront than Prisma does, since Prisma is generally the easier on-ramp for total beginners. Using Drizzle well also genuinely requires understanding joins, relations, indexes, and how queries actually work, there's no hiding from that. And its ecosystem, documentation, and community, while solid, are still smaller than Prisma's more mature setup.

The simplest way to frame the difference is this. With Prisma you treat the database like a bunch of objects, prisma.user.findMany(), and the whole focus is developer experience. With Drizzle you treat the database more like SQL itself, db.select().from(users), and the focus shifts toward performance and control.

Looking at all three side by side

At this point we've covered three real approaches, raw SQL, Prisma, and Drizzle, and architecturally they stack up like this.

Raw SQL:      Application → SQL Query → Database
Prisma:       Application → Prisma Client → SQL → Database
Drizzle:      Application → Drizzle → SQL → Database

Take one simple operation, finding a user by email, given a basic users table with id, name, and email. Here's how each approach handles the exact same task.

Raw SQL:

const result = await pool.query(
`
SELECT *
FROM users
WHERE email=$1
`,
["rahul@test.com"]
);

Prisma:

const user =
await prisma.user.findUnique({

where:{
 email:"rahul@test.com"
}

});

Drizzle:

const user =
await db
.select()
.from(users)
.where(
 eq(
 users.email,
 "rahul@test.com"
 )
);

All three get you the exact same data back at the end of the day. What actually differs is how much control you want, how much abstraction you're comfortable with, and how much SQL you already know going in.

A mistake a lot of beginners make here is fixating on "which one's the fastest," when in real projects that's rarely the question that actually matters. The better questions are usually things like what the team's already comfortable with, how complex the project genuinely is, how strong everyone's database knowledge actually is, and how complicated the queries are likely to get. A simple SaaS app can usually get by just fine on Prisma alone. A database heavy application is where Drizzle, or even raw SQL in places, starts earning its keep.

Feature	Raw SQL	Prisma	Drizzle
Learning curve	Harder	Easier	Medium
SQL Control	Highest	Lowest	High
Type Safety	Low	Excellent	Excellent
Performance	Excellent	Good	Excellent
Developer Experience	Medium	Excellent	Good
Complex Queries	Excellent	Medium	Excellent
Beginner Friendly	Low	High	Medium

So what should you actually choose

Should you always default to using an ORM? No, honestly. An ORM is a tool like any other, and no single tool is the right call for every project out there. Some apps genuinely move faster with one, others are better off without.

Raw SQL earns its place when you need maximum control over the database, when the app is genuinely database heavy, when queries get complex, or when performance really can't take a hit. Think analytics platforms, reporting systems, financial applications, or anything doing heavy data processing. Say you need a report answering something like "how much has each customer purchased over the last five years, and what's their average order value." That kind of query is just naturally easier to express directly in SQL.

SELECT
customers.name,
COUNT(orders.id),
AVG(orders.amount)

FROM customers

JOIN orders

ON customers.id = orders.customer_id

GROUP BY customers.name;

There's really no substitute for SQL's raw power in cases like that. The catch is that leaning entirely on raw SQL across a large codebase gets unwieldy fast, hundreds of scattered query files, and you're left manually managing type safety yourself on top of it all.

Prisma tends to be the better call when you're building a TypeScript backend, doing mostly standard CRUD work, care about development speed, and have multiple developers working across the same codebase. Think SaaS products, admin dashboards, e-commerce APIs, or content management systems, basically anywhere operations like creating a user, updating a profile, creating an order, or pulling dashboard data are the daily bread and butter. Prisma genuinely boosts productivity here, turning something like a raw SELECT * FROM users WHERE id=1 into a clean, readable prisma.user.findUnique({ where: { id: 1 } }) that any teammate can understand at a glance.

Drizzle earns its spot when you're working in TypeScript, already know SQL reasonably well, care a lot about performance and control, and want something lightweight rather than heavy handed. It tends to appeal to developers who want the safety net of an ORM without feeling like they've been pulled too far away from the actual database.

In practice, plenty of real projects don't stick to just one approach. A startup might reasonably begin like this.

Express → Prisma → PostgreSQL

Which is a genuinely practical starting point. As the app grows and analytics or complex reporting needs pile up, it's common to start layering raw SQL into specific parts of the app rather than ripping out Prisma entirely.

Application
├── Prisma
└── Raw SQL Queries
        ↓
   PostgreSQL

Using one approach everywhere isn't some rule you're required to follow, and most real world codebases end up mixing them anyway. Startups often lean toward TypeScript plus Prisma plus PostgreSQL purely for development speed. Newer, more modern TypeScript projects increasingly reach for Drizzle instead, valuing that lightweight, SQL friendly approach. And larger scale systems often end up combining an ORM with raw SQL and dedicated database optimization work, simply because different parts of a large system run into genuinely different problems.

Mistakes worth avoiding

A few things trip people up consistently here. The first is treating the ORM itself as the database. Prisma isn't a database, Drizzle isn't a database, they're just tools for accessing one, whether that's PostgreSQL, MySQL, or MongoDB sitting underneath.

The second is skipping SQL entirely and jumping straight to Prisma. It feels productive early on, but it tends to backfire later when slow queries stop making sense, joins feel needlessly confusing, and database optimization becomes genuinely hard because there's no real foundation underneath the abstraction. An ORM was never meant to replace SQL, it's a layer sitting on top of it.

The third is chasing raw performance numbers above everything else. Developer productivity matters just as much in the real world. Shaving five milliseconds off a query while making development three months slower isn't automatically the smarter trade to make.

A learning path worth following

If starting from zero today, this is roughly the order worth going in. Start with SQL fundamentals, tables, primary keys, foreign keys, joins, indexes, transactions, all using something like PostgreSQL. Then spend some real time connecting directly with something like Node's pg package, so you actually understand how an application talks to a database without anything hidden in between. From there, move into Prisma, get comfortable with schemas, migrations, relations, and the type safety it brings. And finally, give Drizzle a proper try, so you understand what an SQL-first approach with a query builder actually feels like, along with the performance trade-offs that come with it.

Where that leaves you

The point of an ORM was never to replace SQL. It's there to make the developer experience better, nothing more grand than that.

A genuinely strong backend developer isn't someone who just happens to know Prisma or Drizzle well. It's someone who understands how a database actually works, how to write SQL when it's needed, what an ORM is actually simplifying for them, and just as importantly, when reaching for an ORM makes sense and when writing raw SQL directly is the smarter call.

Once that clarity sets in, choosing between these tools stops feeling like a guessing game. You start making the call based on what the project actually needs, not on whatever's trending that particular month.

Is Supabase Actually a Database?

Mr. S Gupta — Thu, 20 Aug 2026 14:44:18 +0000

Is Supabase Actually a Database? Sorting Out Supabase, Firebase, Appwrite, PocketBase, and Neon
For a good chunk of my early days learning backend stuff, I genuinely believed Supabase, Firebase, and Appwrite were databases. Just straight up databases, no different from PostgreSQL or MongoDB in my head.

And honestly, the way tutorials talk about them didn't help at all. One video would tell you to just use Supabase and move on. The next would swear by Firebase instead. Then someone else would come along and say skip all of that, just learn PostgreSQL properly.

At some point I genuinely lost track of what I was even picking between. Was I choosing a database? A backend? Some kind of hosting service? Honestly I couldn't tell you at the time.

If that confusion sounds familiar, this should clear most of it up.

The one thing you need to get straight first

A database and a backend platform are not the same thing, and mixing them up is where basically all the confusion starts.

Think about building a house for a second. You need bricks, sure, but you also need wiring, plumbing, security systems, furniture, all of it. The bricks are just one piece of a much bigger picture.

A database works the same way inside your backend. It's just one piece of the whole thing. Modern platforms tend to bundle a bunch of backend services together under one roof, and that's exactly why people end up mistaking the whole platform for just the database part.

So what does a database actually do

A database really only has one job, and it's not glamorous. It stores your data. That's the entire job description.

Take PostgreSQL for example. It stores things in tables.

Users

id	name	email
1	Rahul	rahul@example.com
2	Aman	aman@example.com

It genuinely doesn't care what you're building on top of it, whether that's an online store, a social app, or some banking system. Its only concern is storing and pulling back data when asked.

Okay, so what is Supabase then

Here's the thing people keep getting wrong. Supabase is not a database.

Supabase is a backend platform, and one of the things it happens to include is a PostgreSQL database.

Picture it more like this.

Supabase

├── PostgreSQL Database
├── Authentication
├── File Storage
├── Realtime Engine
├── Edge Functions
├── Dashboard
└── APIs

See how the database is just one item in that list, not the whole thing. Supabase basically hands you a bunch of backend pieces that are already wired together, so instead of setting up each one separately, you get a working backend pretty much out of the box.

What if you skip Supabase entirely

Nothing's actually stopping you from building this exact same setup yourself, piece by piece.

Express

├── PostgreSQL
├── JWT Authentication
├── AWS S3 Storage
├── Socket.IO
├── REST API
└── Docker Deployment

You get total control doing it this way, no argument there. But you're also signing up for a lot more setup work, and honestly a lot more things that can go wrong along the way.

And Firebase

Firebase is also a backend platform, but it's built around a different core. Instead of PostgreSQL, its main database is Firestore, which is a document database, meaning your data lives as documents rather than rows in a table.

Firebase brings along its own bundle of services too.

Firebase

├── Firestore
├── Authentication
├── Cloud Functions
├── Cloud Storage
├── Analytics
├── Hosting
└── Push Notifications

If you've ever built an Android app, you've probably had Firebase suggested to you constantly, and that's mostly because Google has baked it so deeply into its mobile ecosystem.

So is Firebase actually better than Supabase

There's no clean answer here, and honestly anyone who gives you one confidently is probably oversimplifying. They're just solving different problems.

Supabase makes a lot of sense if you're comfortable with PostgreSQL and SQL in general. Firebase makes more sense if your app genuinely benefits from Firestore's structure or from being deep in Google's ecosystem. Which one wins really comes down to what you're building, not which platform is objectively superior.

Where does Appwrite fit in

Appwrite is chasing a pretty similar goal to Supabase. It gives you authentication, a database, file storage, functions, messaging, the usual suite.

What sets it apart is that it's really built with self hosting in mind from the start. If the idea of running your own backend infrastructure instead of leaning on someone else's managed cloud appeals to you, Appwrite is worth a proper look.

And PocketBase

PocketBase is a much smaller, lighter animal compared to Supabase or Firebase. Under the hood it's running on SQLite, which is itself a relational SQL database, and it pairs that with the handy stuff like auth and file storage.

Its whole setup is refreshingly simple.

PocketBase

├── SQLite
├── Authentication
├── File Storage
└── Dashboard

Because it's so lightweight, PocketBase has become a favorite for quick prototypes, demos, and smaller side projects. It's just not usually what people reach for when they're building something that needs to scale up seriously.

Then what exactly is Neon

Compared to everything above, Neon is honestly refreshingly simple to explain. Neon is basically managed PostgreSQL. That's genuinely it, nothing more hidden underneath.

So if someone tells you they're using Neon, all that really means is their PostgreSQL database is being hosted and managed by Neon. There's no built in auth system, no storage service, no bundled backend platform sitting alongside it. Just the database.

Application

↓

Neon

↓

PostgreSQL

That's exactly why a lot of developers pair Neon with something else on top, like Prisma, Drizzle, Clerk, Better Auth, or their own setup on AWS.

Laying them all out side by side

Platform	Database	Type	Extra Backend Services
Supabase	PostgreSQL	SQL	Yes
Firebase	Firestore	NoSQL	Yes
Appwrite	SQL based database support	SQL	Yes
PocketBase	SQLite	SQL	Yes
Neon	PostgreSQL	SQL	No

Look closely and the pattern is obvious. Neon is the only one that's really just about hosting the database itself. Everyone else on that list gives you a whole backend ecosystem wrapped around one.

So which one should a beginner actually go with

Don't pick based on whatever's trending on YouTube this month, that's honestly how a lot of people end up confused in the first place. Pick based on what you're actually trying to learn.

If you want to genuinely understand relational databases, plain PostgreSQL is a solid starting point. If you want authentication, storage, and a dashboard without burning days configuring everything yourself, Supabase is a great pick. If you're building mobile apps and want tight integration with Google's ecosystem, Firebase is the logical choice. If you're just messing around with side projects or prototypes, PocketBase is genuinely convenient. And if owning your own infrastructure matters to you, Appwrite is worth exploring properly.

The mistake almost everyone makes early on

A lot of people end up comparing PostgreSQL directly with Supabase, and honestly that comparison just doesn't hold up. It's a bit like comparing an engine to an entire car.

The comparisons that actually make sense look more like this. PostgreSQL against Firestore. Or Supabase against Firebase. One of those is a database versus database comparison, the other is a platform versus platform comparison. Once that distinction clicks, a huge chunk of the confusion just disappears on its own.

Wrapping up

Whenever some new backend tool crosses your radar, there's really just one question worth asking before anything else. Is this actually a database, or is it a platform built around one?

That single question quietly untangles most backend architecture confusion. Once you know exactly what each piece of the puzzle is actually responsible for, choosing between tools stops feeling like a random guessing game and starts feeling a lot more deliberate.

Next time, I want to go one level up from the database itself and tackle another question beginners run into constantly, what exactly is an ORM, and why do people reach for tools like Prisma or Drizzle instead of just writing raw SQL themselves?