Why I Like Drizzle and Neon for Small SaaS Projects
September 24, 2026 Avishka Devinda
September 24, 2026 Avishka Devinda
When I build a small SaaS project, I want the database layer to be boring.
I want PostgreSQL, migrations I can understand, type safety, and as little infrastructure as possible. That is why I like using Drizzle ORM with Neon Postgres.
It gives me a setup that feels modern without hiding the database behind too much abstraction.
Neon gives me PostgreSQL without needing to manage a PostgreSQL server myself.
For side projects and SaaS MVPs, that removes a lot of work. I can create a database, copy the connection string, add it to my environment variables, and start building.
The important part for me is that it is still PostgreSQL.
I can use normal SQL concepts:
I am not learning a custom database model that only exists on one platform.
Drizzle feels closer to SQL than many traditional ORMs.
A schema can look like this:
import { pgTable, text, timestamp, uuid } from 'drizzle-orm/pg-core';
export const projects = pgTable('projects', {
id: uuid('id').defaultRandom().primaryKey(),
name: text('name').notNull(),
createdAt: timestamp('created_at').defaultNow().notNull(),
});
Then a query still reads like a database query:
const projects = await db
.select()
.from(projectsTable);
I like that because I can usually understand what SQL will be generated.
The biggest reason I use Drizzle is not that I want to avoid SQL.
It is the opposite.
I want SQL-like control while still getting TypeScript types.
If I rename a field in my schema, TypeScript can help me find the places that need updating. If I select specific columns, the result type follows the query.
That gives me useful safety without making the database feel magical.
Modern Next.js applications often run server-side code in short-lived functions rather than one long-running server.
That changes how database connections should be handled.
Neon provides serverless-friendly connection options, and Drizzle supports Neon drivers directly. For simple queries and many SaaS workloads, the HTTP-based connection model is convenient because I do not have to maintain a traditional long-lived connection pool inside every function.
For more complex transaction requirements, I can choose a different connection approach.
I like having that choice.
I do not want database changes to exist only in a dashboard.
My schema and migrations should live with the code.
A normal workflow might look like:
npx drizzle-kit generate
npx drizzle-kit migrate
That means a database change becomes part of the repository and can be reviewed like any other code change.
This becomes more important as a project grows.
For a small SaaS project, I normally start with only a few tables:
I try not to create a complex database design before the product needs it.
PostgreSQL is powerful enough that I can evolve the structure later.
I think Drizzle and Neon are a good fit for:
It is especially nice when I already use TypeScript everywhere else.
No stack is perfect.
If a project has extremely complex database behavior, very high sustained traffic, or special infrastructure requirements, I would evaluate the database architecture separately instead of picking Neon automatically.
The same applies to Drizzle. If a team already has deep experience with another ORM and it solves the problem well, changing tools just because something is newer usually does not make sense.
For the projects I build most often, I want a database stack that stays understandable.
Neon gives me PostgreSQL without server management.
Drizzle gives me a typed query layer without making me forget SQL.
Together, they let me spend more time building the product instead of building database infrastructure around the product.