Where Does Application Data Live After a User Closes the App?

At first, this may sound like a simple question. But it leads directly to one of the most fundamental concepts in software development: persistent data storage.

A user can close their browser, restart their phone, shut down their computer, or log out of an application. Yet when they return, their account, orders, messages, posts, payments, and preferences are still expected to be there.

That information cannot exist only inside the running application. It needs to be stored somewhere that is designed to preserve it reliably over time.

That is where a database comes in.

Modern applications can communicate with databases in several ways. Developers can write SQL directly, use traditional Object-Relational Mappers (ORMs), or work with modern database tools such as Prisma and Drizzle, which combine database access with strong TypeScript support.

Before comparing these tools, however, it is important to understand the problem they are designed to solve.

---

1. Why Do Applications Need Databases?

Consider a typical e-commerce application.

A customer creates an account, adds products to a cart, places an order, and completes a payment. If all of that information disappeared whenever the server restarted, the application would be practically unusable.

The application needs to permanently remember information such as:

• Users — names, email addresses, preferences

• Products — names, prices, inventory

• Orders — what was purchased and by whom

• Payments — transaction details and payment status

• Reviews — customer feedback

• Addresses — shipping and billing information

This is known as persistent storage: information remains available even after a particular process, request, or session has ended.

Structured vs. Unstructured Data

Not all application data has the same structure.

A user account, for example, usually follows a predictable format:

User
├── id
├── name
├── email
└── createdAt

This is structured data because its fields and relationships can be clearly defined.

Other types of data are much less predictable. Images, videos, audio files, documents, and arbitrary text are often considered unstructured data.

Modern applications commonly use both.

For example, a social media application might store user profiles, posts, and metadata in a database while keeping uploaded images and videos in object storage.

A Database as the Application's Long-Term Memory

One useful way to think about a database is as the application's long-term memory.

The frontend displays information, the backend handles business logic, and the database provides durable storage.

A simplified architecture looks like this:

User
  ↓
Frontend
  ↓
Backend / API
  ↓
Database

The database is therefore much more than a place to "put data." It is a fundamental part of an application's architecture.

---

2. SQL vs. NoSQL Databases

Once an application requires persistent storage, another question appears:

What type of database should it use?

Two broad categories developers commonly encounter are SQL and NoSQL databases.

SQL Databases

SQL databases are generally relational databases. They organize information into tables containing rows and columns.

For example:

Users

id	name	email
1	Alice	alice@example.com
2	Bob	bob@example.com

An orders table might look like:

Orders

id	user_id	total
101	1	59.99
102	2	25.00

The user_id field creates a relationship between an order and the user who placed it.

Popular relational databases include:

• PostgreSQL

• MySQL

• MariaDB

• SQLite

• Microsoft SQL Server

• Oracle Database

SQL databases are particularly useful when an application has strong relationships between different types of data and requires features such as transactions, constraints, consistency, and complex queries.

E-commerce systems are a classic example.

A customer can have multiple orders, an order can contain multiple products, and each payment needs to be connected to a particular order.

NoSQL Databases

The term NoSQL generally refers to databases that do not primarily rely on the traditional relational table model.

One common type is a document database.

Instead of distributing user information across multiple rows and related tables, a document database might represent a user as a single document:

{
  "id": 1,
  "name": "Alice",
  "email": "alice@example.com",
  "preferences": {
    "theme": "dark"
  }
}

Popular NoSQL databases include:

• MongoDB

• DynamoDB

• Cassandra

• Couchbase

NoSQL databases can be useful when the data structure needs to be highly flexible, when a particular scalability model is required, or when a document-oriented structure naturally matches the application.

SQL vs. NoSQL Isn't "Old vs. New"

One common misconception is that SQL databases are outdated while NoSQL databases represent the modern approach.

That is not the right way to think about the distinction.

The better question is:

Which data model and operational characteristics are appropriate for the application?

A relational database can be an excellent choice for a modern SaaS platform, e-commerce system, financial application, or internal business tool.

Likewise, a document database can be a great choice when flexible document structures are central to the problem.

The goal is not to choose the newest technology. The goal is to choose the technology that fits the application's requirements.

---

3. The Challenge of Raw Database Queries

Suppose a backend needs to retrieve a user from a relational database.

A developer might write:

SELECT id, name, email
FROM users
WHERE id = 42;

To retrieve orders:

SELECT id, user_id, total
FROM orders
WHERE user_id = 42;

And to retrieve a product:

SELECT id, name, price
FROM products
WHERE id = 100;

There is nothing inherently wrong with SQL. In fact, SQL is extremely powerful.

The difficulty begins when an application contains hundreds or thousands of database operations.

Developers may need to manage:

• Query construction

• Parameters

• Result mapping

• Validation

• Transactions

• Database connections

• Error handling

• Schema changes

• Type mismatches

• Repeated database-access patterns

Security is another major concern.

Poorly constructed SQL queries can introduce SQL injection vulnerabilities.

For example, dynamically inserting user input directly into a query is dangerous:

"SELECT * FROM users WHERE email = '" + userInput + "'"

Modern database libraries provide parameterized queries and other mechanisms that make secure database access significantly easier.

The Bigger Problem Is Maintainability

Writing one SQL query is usually not difficult.

The real challenge is maintaining hundreds or thousands of queries across a large application.

If database operations are scattered throughout the codebase, even a simple schema change can become expensive and risky.

This creates a need for a layer between the application and the database.

That is where database libraries and ORMs become useful.

---

4. What Is an ORM?

ORM stands for Object-Relational Mapping.

The concept is fairly simple:

An ORM maps concepts in application code to records and relationships in a relational database.

Suppose an application has a User object:

User
├── id
├── name
└── email

The database might contain a corresponding users table:

users
├── id
├── name
└── email

The ORM provides a programming interface that allows developers to work with database data using concepts from their programming language.

Conceptually:

Application Objects
        ↕
       ORM
        ↕
Database Records

Instead of manually writing SQL for every operation, a developer might write something conceptually similar to:

Find user where id = 42

The ORM handles much of the translation into database operations.

Why Do ORMs Exist?

The goal of an ORM is not necessarily to eliminate SQL.

Its primary purpose is to make application development more productive, consistent, and maintainable.

An ORM can provide several benefits.

1. Abstraction

Developers interact with a consistent programming interface instead of manually handling every database operation.

2. Type Safety

Modern database tools can understand the database schema and provide useful compile-time feedback.

3. Relationships

ORMs can make relationships easier to represent and work with.

For example:

User
 ↓
Orders

4. Migrations

Many ORM ecosystems provide tools for evolving the database schema as an application changes.

5. Developer Tooling

Features such as autocomplete, generated types, validation, and IDE integration can make database development much easier.

ORMs Are Not Magic

An important architectural lesson is that an ORM does not make the database disappear.

Behind the abstraction, the database still contains:

• Tables

• Indexes

• Constraints

• Transactions

• Query planners

• Locks

• Joins

• Storage engines

If developers do not understand these concepts, an ORM can sometimes hide problems rather than solve them.

For example, a simple-looking ORM operation could generate an inefficient database query.

So the key principle is:

An ORM is a productivity tool, not a replacement for database knowledge.

ORMs also come with tradeoffs. They can introduce abstraction overhead, hide SQL details, and sometimes make highly complex queries more difficult to express.

This is one reason tools such as Prisma and Drizzle take different approaches.

---

5. Understanding Prisma

Prisma is a modern database toolkit for TypeScript and JavaScript applications.

Instead of treating database access as a collection of SQL strings, Prisma provides a strongly typed developer experience built around an application's data model.

One of its defining ideas is schema-first development.

A Prisma schema describes the application's data model.

Conceptually:

User
├── id
├── name
├── email
└── orders

Order
├── id
├── total
└── user

Prisma's tooling can then generate a type-safe database client from that schema.

The development workflow can be visualized as:

Prisma Schema
      ↓
Prisma Tooling
      ↓
Generated Database Client
      ↓
Application
      ↓
Database

Type-Safe Database Access

One of Prisma's biggest strengths is its developer experience.

Suppose a User has the following fields:

id
name
email

Your editor can understand these fields when you work with the Prisma client.

As a result, mistakes such as referencing a field that does not exist can often be detected during development instead of appearing unexpectedly at runtime.

This becomes increasingly valuable as applications and development teams grow.

Migrations

Prisma also provides database migration tooling.

Suppose a user initially has:

User
├── id
├── name
└── email

Later, the application adds:

createdAt

The database needs to change as well.

A migration represents that change and allows the database schema to evolve alongside the application.

This makes database changes part of the normal software development workflow instead of relying on undocumented manual changes.

Developer Experience

Prisma provides tooling around areas such as:

• Data modeling

• Database access

• Migrations

• Type generation

• Development workflows

• Database inspection and management

This makes Prisma attractive to teams that want developers to spend less time manually managing database-access details.

The tradeoff is that Prisma introduces a more substantial abstraction layer between the application and the database.

---

6. Understanding Drizzle

Drizzle follows a different philosophy.

Instead of placing a large abstraction between developers and SQL, Drizzle emphasizes a SQL-first approach while still providing strong TypeScript type safety.

Its philosophy can be summarized as:

Stay close to SQL while making database development feel natural in TypeScript.

For developers who already understand SQL, this approach can be particularly appealing.

Conceptually:

TypeScript
    ↓
Drizzle
    ↓
SQL Concepts
    ↓
Database

Drizzle provides typed APIs for constructing database queries while keeping relational concepts visible.

A Lightweight Approach

Drizzle is often described as lightweight compared with traditional ORM approaches.

Rather than completely hiding the database behind objects and abstractions, it gives developers a typed way to work directly with database structures.

This can make complex SQL concepts easier to reason about, particularly for developers who prefer explicit control.

For example, developers can continue thinking in terms of:

SELECT
JOIN
WHERE
ORDER BY
GROUP BY

while still benefiting from TypeScript's type system.

Drizzle vs. Traditional ORMs

Traditional ORM thinking often looks like:

Application Objects
        ↓
ORM Abstraction
        ↓
Database

Drizzle is closer to:

TypeScript
    ↓
SQL-like Query Builder
    ↓
Database

This difference is important.

Prisma generally emphasizes a developer-friendly abstraction, while Drizzle emphasizes type-safe proximity to SQL.

Neither philosophy is universally better.

The right choice depends on the application and the development team's preferences and expertise.

---

7. Prisma vs. Drizzle

The most useful question is not:

"Which one is better?"

A better question is:

Which abstraction fits the application's architecture and the team's way of working?

Area	Prisma	Drizzle
Philosophy	Higher-level, schema-oriented	SQL-first
Type safety	Strong	Strong
SQL exposure	More abstracted	More visible
Developer experience	Highly integrated	Lightweight and explicit
Learning curve	Approachable for many application developers	Particularly comfortable for SQL users
Database control	More abstract	More direct
Migrations	Integrated workflow	SQL-oriented migration tooling
Complexity	More abstraction	Less abstraction
Best fit	Teams wanting a polished ORM-style workflow	Teams wanting SQL control with TypeScript safety

Developer Experience

Prisma tends to appeal to developers who want an integrated database development experience.

You define the model, generate the client, and interact with the database through a strongly typed API.

Drizzle tends to appeal to developers who want more visibility into how the database is being queried.

Learning Curve

Prisma can be approachable for developers who are comfortable with application-level abstractions but do not want to learn every SQL detail immediately.

Drizzle can feel particularly natural to developers who already think in SQL.

However, both tools benefit greatly from a solid understanding of relational databases.

Performance Considerations

It is tempting to ask:

"Which is faster, Prisma or Drizzle?"

That question is usually too simplistic.

Real-world database performance depends on many factors, including:

• Query design

• Indexes

• Database configuration

• Network latency

• Connection pooling

• Number of queries

• Data volume

• Join complexity

• Caching

• Overall application architecture

The difference between two database libraries may be far less important than whether an application performs a handful of efficient queries or hundreds of unnecessary ones.

For performance-sensitive systems, the best approach is to benchmark the actual workload rather than relying on generic performance claims.

Type Safety

Both Prisma and Drizzle aim to provide strong TypeScript safety, but they approach it differently.

Prisma derives much of its developer experience from its schema and generated client.

Drizzle keeps type information closely connected to the database schema and its query-building APIs.

In both cases, the architectural benefit is similar:

Database Structure
       ↓
Type Information
       ↓
Application Code

This reduces the gap between what the database actually contains and what the application assumes exists.

Ecosystem and Production Use

Prisma has established itself as a prominent database toolkit in the TypeScript ecosystem and has built a substantial developer ecosystem around its approach.

Drizzle has gained significant attention among developers who prefer lightweight, SQL-oriented tooling.

Both can be appropriate for production systems.

The more important question is whether the tool fits:

• Your database

• Your framework

• Your team's expertise

• Your deployment environment

• Your query complexity

• Your maintenance requirements

---

8. Database Migrations

As an application grows, its database schema inevitably changes.

A prototype might begin with:

User
├── id
├── name
└── email

Later, the product might require:

User
├── id
├── name
├── email
├── avatar
├── createdAt
└── updatedAt

Eventually, the system might introduce additional concepts such as:

Subscription
Payment
Organization
Team
Role

The database must evolve alongside the application.

That is where migrations become essential.

What Is a Migration?

A migration is a versioned change to a database schema.

For example:

Migration 001
Create users
      ↓
Migration 002
Create products
      ↓
Migration 003
Create orders
      ↓
Migration 004
Add createdAt to users

Instead of manually modifying a production database and hoping everyone remembers what changed, schema modifications become part of the application's history.

Why Do Migrations Matter?

Migrations provide several important benefits.

Reproducibility

A new developer can recreate the database structure using the migration history.

Version Control

Database changes can be stored alongside application code in source control.

Collaboration

Developers can see how the schema has evolved and understand why changes were introduced.

Deployment Consistency

Production environments can apply known database changes in a controlled sequence.

Common Migration Challenges

Migrations become more complicated when an application already contains production data.

For example, adding a required column to a table containing millions of records requires significantly more planning than adding the same column to an empty development database.

Teams may need to consider:

• Backward compatibility

• Data transformations

• Large tables

• Downtime

• Rollbacks

• Deployment order

• Existing application versions

This is why migrations are more than a tooling feature.

They are an important part of software architecture and release engineering.

---

9. Designing Data Models

Before choosing Prisma, Drizzle, or another database tool, developers need to understand how their application's data is structured.

Consider an e-commerce application.

You might have entities such as:

User
Product
Order
OrderItem
Payment

These are the application's major data entities.

The next step is understanding how those entities relate to one another.

One-to-One Relationships

A user might have one profile.

User
 │
 │ 1:1
 ▼
Profile

For example:

User
├── id
└── email

Profile
├── id
├── userId
└── bio

One user corresponds to one profile.

One-to-Many Relationships

A user can place multiple orders.

User
 │
 │ 1:N
 ▼
Orders

For example:

Alice
├── Order #101
├── Order #102
└── Order #103

This is one of the most common relationships in application databases.

Other examples include:

• Author → Blog Posts

• Company → Employees

• Customer → Invoices

• Course → Lessons

Many-to-Many Relationships

Many products can appear in many orders, while each order can contain multiple products.

A relational database commonly represents this relationship using an intermediate table:

Order
  │
  ▼
OrderItem
  ▲
  │
Product

For example:

Order #1001
├── Laptop
├── Mouse
└── Keyboard

The same product can also appear in many different orders.

The intermediate OrderItem entity can store additional information, such as:

quantity
priceAtPurchase

This illustrates an important principle:

Good data modeling reflects the real-world relationships and rules of the application.

---

10. Choosing the Right Tool

There is no universal winner between raw SQL, Prisma, Drizzle, or other database libraries.

The right choice depends on the problem you are solving.

Startup Projects

Startups often prioritize:

• Fast development

• Easy onboarding

• Strong TypeScript integration

• Simple migrations

• Developer productivity

A higher-level ORM such as Prisma can be attractive for teams that want a structured and integrated development experience.

Drizzle can also be an excellent choice when the team prefers SQL-oriented development.

Enterprise Applications

Large organizations often care about:

• Long-term maintainability

• Team consistency

• Database governance

• Testing

• Observability

• Migration discipline

• Complex queries

• Operational reliability

At this scale, understanding the underlying database is often more important than the particular ORM being used.

An abstraction that works extremely well for one team may become restrictive for another.

Team Experience

The team's existing knowledge should also influence the decision.

If most developers are comfortable with application-level abstractions but have limited SQL experience, Prisma may feel more natural.

If the team has strong SQL expertise and wants database concepts to remain visible, Drizzle may be a better fit.

In many cases, the best tool is simply the one your team can understand, operate, and maintain confidently.

Long-Term Maintenance

A database layer can survive much longer than the developer who originally built it.

When evaluating a database tool, ask:

• Will new developers understand it?

• Is the schema easy to reason about?

• Are migrations reproducible?

• Can complex queries be expressed clearly?

• Can developers access lower-level database features when necessary?

• Is the tooling actively maintained?

These questions are often more important than choosing whichever library is currently trending.

Performance Requirements

For most applications, the biggest performance improvements do not come from switching ORM libraries.

They usually come from better database and application design:

Good Schema
    +
Good Indexes
    +
Efficient Queries
    +
Connection Management
    +
Caching Where Appropriate
    +
Sound Application Architecture

For applications with demanding database workloads, developers should understand SQL and the database engine regardless of which abstraction they choose.

---

11. The Bigger Picture

Prisma and Drizzle are sometimes presented as competitors in a race to become the "best ORM."

A more useful way to look at them is as different solutions to the same fundamental problem:

How should application code communicate with persistent data safely, efficiently, and maintainably?

The architecture can be simplified to:

┌───────────────────────────┐
│        Application        │
│                           │
│       Business Logic      │
└─────────────┬─────────────┘
              │
              ▼
┌───────────────────────────┐
│   Database Access Layer   │
│                           │
│   Prisma / Drizzle / SQL  │
└─────────────┬─────────────┘
              │
              ▼
┌───────────────────────────┐
│         Database          │
│                           │
│ PostgreSQL / MySQL / etc. │
└───────────────────────────┘

The database remains the foundation.

Prisma, Drizzle, or raw SQL simply represent different ways of building the layer that connects application code to that foundation.

---

Conclusion

Modern applications depend on databases because application state needs to survive beyond the lifetime of a process, request, or user session.

As an application grows, manually managing every query, relationship, type, transaction, and schema change becomes increasingly difficult.

That is why database-access tools exist.

ORMs provide abstractions that allow developers to work with database records through application-level concepts.

Prisma emphasizes a schema-driven, highly integrated developer experience with strong generated typing.

Drizzle takes a more SQL-first and lightweight approach while preserving the benefits of TypeScript's type system.

Neither approach eliminates the need to understand databases.

In fact, as applications become larger and more complex, database fundamentals become even more important:

• Relational data modeling

• Indexes

• Transactions

• Query optimization

• Constraints

• Migrations

• Connection management

The best developers do not treat Prisma or Drizzle as magic layers that make databases irrelevant.

Instead, they view these tools as ways to manage the boundary between application code and persistent data.

And that leads to the most important architectural lesson:

Choose the abstraction that helps your team work effectively without hiding the database concepts your application depends on.

Whether you ultimately choose raw SQL, Prisma, Drizzle, or another database toolkit, a strong understanding of the underlying data model will remain one of the most valuable skills an application developer can have.