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

Imagine you're using an e-commerce application. You create an account, add products to your cart, place an order, and close the app.

The next day, you open the app again. Your account still exists. Your order history is available. Your payment details have been processed.

But where did all that information go after you closed the application?

The answer is simple: databases.

Databases are the foundation of modern software systems. Whether it's social media platforms, online stores, banking applications, or blogging websites, databases store and organize information so applications can retrieve it whenever needed.

As applications grow, developers need efficient ways to interact with databases. This is where technologies like ORMs, Prisma, and Drizzle become important.

In this article, we'll explore how modern applications access databases, why ORMs exist, and how Prisma and Drizzle are changing the developer experience.

---

Why Applications Need Databases

Applications generate and consume data constantly.

Consider a few common examples:

E-Commerce Platform

• Users

• Products

• Orders

• Payments

• Reviews

Social Media Platform

• User profiles

• Posts

• Comments

• Likes

• Followers

Blogging Platform

• Authors

• Articles

• Categories

• Tags

• Comments

If this data existed only in application memory, everything would disappear whenever the application restarted.

Databases solve this problem by providing permanent storage.

Structured vs Unstructured Data

Structured Data

Structured data follows predefined rules and formats.

Example:

User ID	Name	Email
1	John	john@email.com
2	Sarah	sarah@email.com

This data fits neatly into rows and columns.

Unstructured Data

Unstructured data doesn't follow a fixed format.

Examples:

• Images

• Videos

• Documents

• Chat messages

• Audio files

Modern applications often manage both structured and unstructured information.

Databases become the central source of truth that enables applications to function reliably.

---

SQL vs NoSQL Databases

Not all databases work the same way.

The two most common categories are SQL and NoSQL databases.

SQL Databases

SQL (Structured Query Language) databases store information in tables.

Popular examples include:

• PostgreSQL

• MySQL

• Microsoft SQL Server

• SQLite

Example:

Users Table

id	name
1	Alice
2	Bob

Orders Table

id	user_id	amount
101	1	500

Relationships between tables are a core strength of SQL databases.

NoSQL Databases

NoSQL databases store information in more flexible formats.

Popular examples:

• MongoDB

• Cassandra

• Redis

Instead of tables, data is often stored as documents.

Example:

{
  "name": "Alice",
  "orders": [
    {
      "amount": 500
    }
  ]
}

When Should You Choose SQL?

SQL works best when:

• Relationships are important

• Data consistency matters

• Complex queries are required

• Financial transactions are involved

When Should You Choose NoSQL?

NoSQL is useful when:

• Data structure changes frequently

• Large-scale distributed systems are required

• Flexibility is more important than strict relationships

There is no universal winner. The right choice depends on application requirements.

---

The Problem with Raw Database Queries

Traditionally, developers communicate with databases using raw SQL queries.

Example:

SELECT * FROM users WHERE id = 1;

This works well initially.

However, as applications grow, several problems emerge.

Repetitive Code

Developers repeatedly write similar queries:

SELECT * FROM users;
SELECT * FROM products;
SELECT * FROM orders;

This creates duplication throughout the codebase.

Security Risks

Improperly constructed queries can introduce vulnerabilities such as SQL injection attacks.

Example:

SELECT * FROM users WHERE email = 'user input';

If user input isn't handled correctly, attackers may manipulate database behavior.

Maintainability Issues

Imagine hundreds of SQL queries scattered across dozens of files.

Changing a database column name could require updating numerous queries manually.

Scaling Challenges

As teams grow:

• More developers write queries

• More tables are added

• Business logic becomes complex

Managing raw queries becomes increasingly difficult.

This challenge led to the rise of ORMs.

---

What is an ORM?

ORM stands for Object Relational Mapping.

An ORM acts as a bridge between application code and the database.

Instead of writing SQL manually, developers interact with objects and methods.

Traditional Architecture

Application
      ↓
 Raw SQL
      ↓
 Database

ORM Architecture

Application
      ↓
     ORM
      ↓
 Database

The ORM translates application code into database queries.

Example

Without ORM:

SELECT * FROM users WHERE id = 1;

With ORM:

user.findById(1)

The ORM generates the SQL automatically.

Why ORMs Exist

They improve:

• Productivity

• Consistency

• Maintainability

• Developer experience

Benefits of ORMs

Faster Development

Less SQL means quicker implementation.

Better Readability

Code often becomes easier to understand.

Database Abstraction

Switching databases becomes simpler.

Type Safety

Many modern ORMs detect errors before runtime.

Tradeoffs

ORMS are not magic.

Potential drawbacks include:

• Performance overhead

• Learning curve

• Hidden complexity

• Reduced control over generated SQL

Understanding these tradeoffs is essential when choosing a database access strategy.

---

Understanding Prisma

Prisma is one of the most popular modern ORMs in the JavaScript and TypeScript ecosystem.

Its primary goal is improving developer experience through strong type safety and automation.

Schema-First Development

Prisma starts with a schema file.

Example conceptually:

User
- id
- name
- email

This schema becomes the single source of truth.

Prisma then generates database access code automatically.

Type-Safe Database Access

One of Prisma's biggest advantages is type safety.

Developers receive:

• Auto-completion

• Compile-time validation

• Reduced runtime errors

This is especially valuable in large TypeScript applications.

Migrations

Prisma includes built-in migration tooling.

Developers can:

• Add new fields

• Create tables

• Modify relationships

while maintaining database version history.

Developer Experience

Prisma emphasizes:

• Simplicity

• Automation

• Productivity

This makes it highly attractive for startups and rapidly growing teams.

Prisma Ecosystem

Prisma offers:

• Schema management

• Query generation

• Migration tools

• Database introspection

• Developer tooling

The result is a highly integrated database workflow.

---

Understanding Drizzle

Drizzle approaches database access differently.

Rather than abstracting SQL heavily, Drizzle embraces SQL concepts while adding type safety.

SQL-First Philosophy

Drizzle is often described as:

"A TypeScript ORM that feels close to SQL."

Instead of hiding database concepts, it exposes them clearly.

Type Safety

Like Prisma, Drizzle provides strong TypeScript support.

Developers receive:

• Typed queries

• Compile-time checks

• Safer database operations

Lightweight Architecture

Drizzle focuses on minimal abstraction.

Benefits include:

• Smaller footprint

• Lower overhead

• Greater transparency

Closer to SQL

Many developers prefer Drizzle because generated queries feel more predictable.

Rather than abstracting everything away, Drizzle keeps developers closer to database fundamentals.

Drizzle vs Traditional ORMs

Traditional ORMs often prioritize abstraction.

Drizzle prioritizes:

• SQL familiarity

• Explicit control

• Lightweight architecture

This appeals particularly to experienced developers who want flexibility.

---

Prisma vs Drizzle

The comparison isn't about which tool is better.

It's about which tool better matches your needs.

Developer Experience

Prisma

• Highly polished

• Beginner-friendly

• Strong tooling

Drizzle

• More explicit

• Closer to SQL

• Greater transparency

Learning Curve

Prisma generally feels easier for newcomers.

Drizzle often feels natural for developers already comfortable with SQL.

Performance

Both perform well in production.

However, Drizzle's lightweight design may introduce less abstraction overhead.

For most applications, performance differences are rarely the deciding factor.

Migration Workflow

Prisma provides a highly integrated migration experience.

Drizzle offers migrations while maintaining greater flexibility.

Type Safety

Both provide excellent TypeScript support.

This is one reason they have become popular choices in modern web development.

Ecosystem Maturity

Prisma has been widely adopted for longer and offers a larger ecosystem.

Drizzle is newer but growing rapidly.

Production Use Cases

Prisma often fits:

• SaaS applications

• Startup products

• Teams prioritizing productivity

Drizzle often fits:

• Performance-focused systems

• SQL-heavy applications

• Teams wanting greater database control

Database Migrations

Applications evolve.

Databases must evolve too.

This is where migrations become important.

Why Migrations Are Needed

Imagine an application initially storing:

User
- id
- name

Later, the business requires:

User
- id
- name
- email

The database structure must change safely.

Schema Evolution

Migrations track these changes over time.

Example:

Version 1:

User
- id
- name

Version 2:

User
- id
- name
- email

Version 3:

User
- id
- name
- email
- phone

Benefits

Migrations provide:

• Version control

• Team collaboration

• Repeatable deployments

• Rollback capability

Common Challenges

• Data loss risks

• Large table updates

• Downtime concerns

• Production synchronization

Proper migration planning becomes increasingly important as applications scale.

---

Designing Data Models

A database is ultimately a model of the real world.

Good design starts with understanding relationships.

One-to-One Relationship

Example:

User ↔ Profile

Each user has exactly one profile.

Each profile belongs to one user.

---

One-to-Many Relationship

Example:

User → Orders

One user can have many orders.

Each order belongs to one user.

User
 ├─ Order 1
 ├─ Order 2
 └─ Order 3

---

Many-to-Many Relationship

Example:

Students ↔ Courses

A student can enroll in many courses.

A course can contain many students.

Student A → Course 1
Student A → Course 2

Student B → Course 1
Student B → Course 3

This relationship typically requires an intermediate table.

Modeling Real Systems

Every successful application depends on effective modeling.

Examples:

• Users and roles

• Products and categories

• Posts and tags

• Customers and subscriptions

Good database design often matters more than ORM selection.

---

Choosing the Right Tool

There is no universally correct answer.

The best choice depends on context.

Choose Prisma When

• Team productivity is critical

• Developers are newer to SQL

• Strong tooling is desired

• Rapid development is required

Choose Drizzle When

• SQL knowledge is strong

• Transparency matters

• Lightweight architecture is preferred

• Greater query control is needed

Consider Team Experience

Technology choices should align with the team's expertise.

A highly skilled SQL team may prefer Drizzle.

A fast-moving startup may benefit from Prisma's productivity advantages.

Consider Long-Term Maintenance

Ask questions like:

• Who will maintain this code?

• How often will the schema change?

• How large will the team become?

These considerations often matter more than benchmark comparisons.

---

Conclusion

Modern applications depend on databases to store and organize information long after users close the app. As systems grow, managing database access through raw SQL becomes increasingly difficult, leading to the rise of ORMs.

ORMs are not magic—they are productivity tools that help developers work more efficiently while maintaining database consistency.

Prisma and Drizzle represent two modern approaches to database access:

• Prisma prioritizes developer experience and automation.

• Drizzle prioritizes transparency, SQL familiarity, and lightweight design.

Neither is objectively better.

The real goal is understanding your application's requirements, your team's expertise, and the tradeoffs involved.

Because in software architecture, choosing the right tool is rarely about finding the winner—it's about finding the right fit.