slonik VS drizzle-orm

And sometimes invest instead in learning a technology rather than hide it: for example slonik encourages you to write normal SQL queries by making SQL templating easier and safer. In turn, your IDE would be able to understand those queries and give you support based on the database schemas you actually have.

I'd push you to consider using postgres, slonik or similar for database queries. With these libraries, you just write SQL, but they perform input sanitization for you. So you can safely write:

You can already use postgres with Slonik.

https://github.com/gajus/slonik#user-content-slonik-how-are-...

It is not going to be the default because it is way slower.

https://github.com/gajus/slonik/actions/runs/6616647651

Test node_version:18 test_only:postgres-integration is taking 3 minutes.

Test node_version:18 test_only:pg-integration is taking 38 seconds.

For those uninitiated, Slonik is a battle-tested SQL query building and execution library for Node.js. Its primary goal is to allow you to write and compose SQL queries in a safe and convenient way. Now, let's see how it pairs with Express.js.

I am the maintainer of Slonik and I am trying to understand what portion of this sub-users are using Slonik vs other libraries, and if they are using anything else – what are their reasons for it.

It's nice that they implemented string templates essentially exactly the same way Javascript template literals and tag functions work. They even give an example of using it to create a prepared statement (e.g. DB."SELECT * FROM foo WHERE bar = \{inputParam}") which is exactly what many NodeJS libraries due, e.g. Slonik https://github.com/gajus/slonik, like sql`SELECT * FROM foo WHERE bar = ${inputParam}`;

I've found libraries like Zod useful when interacting with external data sources like a database. Slonik[1] uses Zod to define the types expected from a SQL query and then performs runtime validation on the data to ensure that the query is yielding the expected type.

I don't think it's necessary to use Zod/runtime validation everywhere, but it's a nice tool to have on hand.

[1]https://github.com/gajus/slonik

Demonstrate how easily and accidentally one can make an SQL injection with these:

https://github.com/porsager/postgres

https://github.com/gajus/slonik

Have you tried Slonik (https://github.com/gajus/slonik)? It won't generate types from queries automatically, but it encourages writing SQL vs. a query builder and allows type annotations of queries with Zod. Query results are validated at runtime to ensure the queries are typed correctly.

Drizzle ORM is a very popular TypeScript ORM that provides type safe access to your database, automated migrations, and a custom data model definition.

> being able to have a completely typesafe ORM such as Drizzle (https://orm.drizzle.team/) feels like a Rubicon moment, and touching anything else feels like a significant step backwards.

Alright, but there's nothing stopping you from having a completely typesafe ORM in python, is there?

Sure, there's isn't really one that everyone uses yet, but the python community tends to be a bit more cautious and slower to adopt big changes like that.

Drizzle [1] comes pretty close the last time I checked.

[1]: https://orm.drizzle.team

Each app’s front end is built with Qwik and uses Tailwind for styling. The server-side is powered by Qwik City (Qwik’s official meta-framework) and runs on Node.js hosted on a shared Linode VPS. The apps also use PM2 for process management and Caddy as a reverse proxy and SSL provisioner. The data is stored in a PostgreSQL database that also runs on a shared Linode VPS. The apps interact with the database using Drizzle, an Object-Relational Mapper (ORM) for JavaScript. The entire infrastructure for both apps is managed with Terraform using the Terraform Linode provider, which was new to me, but made provisioning and destroying infrastructure really fast and easy (once I learned how it all worked).

It's just SQL so you can take it out at any moment and move to any other DB provider. The package for working with Astro DB, @astrojs/db, includes Drizzle ORM so migration to a different provider should be relatively painless

Since Vercel's analytics pricing is a bit too expensive for my use case (where I hit the limit of 2,500 requests per month), and I didn't like using Google Analytics (not a big fan of Google), I decided to build my own analytics dashboard. Databases was something I didn't work with much before directly, so I decided to use an ORM, Drizzle, which is quite lightweight and easy to use.

do yourself a favor and ditch Prisma. It's a bloody mess of a project and codebase. I recommend https://github.com/drizzle-team/drizzle-orm to anyone that'll listen.

I myself ran into some issues when I started using drizzle with mysql. They had issues in the way they were handling datetime types. At the time I just used workarounds but then decided to submit a PR since the solution was pretty simple. I just liked drizzle's approach so much that I ended up committing more PRs. At this point, I'm one of the mayor contributors of the library. I think that we have to give some leeway to OSS libraries. Managing OSS is not easy, everybody's issues are important and mayor to them, but there's just so many hours in the day to work for free (or very little). At the end of the day, it's just software prone to have issues.