Is the project healthy?

[extradosages]

Has something happened to impact the drizzle team? There's been a concerning downtick in engagment on GitHub-- a drop in commits and contributors, lack of issue and PR engagement. Website seems stale: latest releases are from august 2024, roadmap has been at 75% since as long as I can remember. Discord has a fair amount of consumer engagement, but doesn't seem like an actual forum for development of the project itself.

This isn't meant to be hostile or inflammatory. If the future of the project is in jeopardy, or if its development is expected to stay low-volume, or if it is just in flux, it would be helpful to know so that our team can prioritize.

[tacomanator]

I'm not involved in Drizzle development so can't comment directly on liveliness, but just under a month ago the new Relational Queries v2 was made available under the beta tag. It's not officially released yet, but appears to be a big effort several months in the making. One could assume this involves a lot of offline planning and experimentation.

https://discord.com/channels/1043890932593987624/1101108758127591435/1349787740186738778

[alex-hall]

IMO No.

I have started accumulating a list of issues with how Drizzle works and am honestly regretting implementing it.

• There's this thread about drizzle not joining where clauses, and the maintainers not wanting to build it even when posed with a fairly common use-case: [FEATURE]: Merge multiple calls to where when in dynamic mode #1644 (comment)
• The schema config is completely ignored in the CLI: [BUG]: drizzle-kit pull doesn't generate the schema file in defineConfig #4436
• Drizzle stumbles when generating models that have varchar and text fields and actually generates invalid typescript: [BUG]:drizzle-kit pull with default varchar or text .default('') does not get generated correctly #4349 . There are like 3 or 4 different versions of this issue that have been open for 6+ months
• In the past it's generated ID column as integers instead of serial columns
• There are countless other issues that I've run into with no good resolution.

It just seems like there is something consistently wrong/broken with fundamental parts of the library. I'm not trying to be rude to any of the maintainers, and I understand that open source development is a thankless and difficult job, but I wouldn't consider the project again for a production use-case.

EDIT: Forgot to mention that the drizzle migration system doesn't have a down, which makes it unsuitable to rely on for production applications

[net]

We also regretted using Drizzle, and ending up ripped it out and replacing it with Kysely, kysely-codegen, and Atlas for migrations. For us, these three tools have been a significant improvement over Drizzle.

I went into a little more detail in #1644 (comment).

[AndriiSherman]

Hey everyone!
I just came across this issue and wanted to share a few clarifications about the current status of the things we’re working on.

First of all, here’s one of the comments I left recently, explaining who the Drizzle team is and why we’re fully committed to this project:
👉 #4614 (comment)

Regarding our plans and ongoing work: I’ve seen a lot of mentions about drizzle-kit bugs, the need for down migrations, and more.

Here’s a major PR we’ve been working on:
👉 #4439
It’s a complete rewrite of the drizzle-kit part. We overhauled its entire architecture based on tons of feedback and responses. We made critical changes to eliminate as many bugs as possible. Our test suite grew from 600 tests to >4k, giving us a solid foundation to add new test cases and ensure long-term stability as we prepare for v1.

This PR also includes a fully reworked foundation for down migrations + foundation to add a support for enabling better collaboration across multiple developers, improved folder structure, support for commutative migrations, and more.
It also introduces support for MSSQL and CockroachDB, bringing us to 85% of our roadmap.

Currently in beta, we have Relational Queries v2, which is ready to be released. But first, we need to add type performance tests to ensure type safety doesn't degrade in v1 or future releases. Once that’s tested and we’ve fixed any type performance issues - we’re going live
This will bring us to 95%

The final 5% includes full support for down migrations and rollbacks, plus bug fixes we’ll make during the final release cycle.
Once that’s in - we’re hitting v1!

[AndriiSherman]

we also have a board of a website to check things we are working on

[extradosages]

Thanks @AndriiSherman. Great to have some input, and thanks for your work on the project.

[AlexDaniel]

@AndriiSherman thank you for drizzle and all the good work! I think people get a bit confused when they visit this page: https://orm.drizzle.team/docs/latest-releases. If that page is not maintained, maybe it's a good idea to remove it altogether (or make it link to github releases).

[AndriiSherman]

@AndriiSherman thank you for drizzle and all the good work! I think people get a bit confused when they visit this page: https://orm.drizzle.team/docs/latest-releases. If that page is not maintained, maybe it's a good idea to remove it altogether (or make it link to github releases).

yeah, agree, we will update it as well

[waynesbrain]

Is there a plan to make building dynamic queries easier? I have been trying for hours to find the right types to pass to do this:

import { mainDb, my_table } from "./db/main"; // given my_table = pgTable("my_table", ...);

const publicRow = () => ({ id: my_table.id, title: my_table.title, things: my_table.things });

 // Now let me pass the dependencies (db, table, selection) and build my own dynamic queries...

 // Which types to use though?? I have experimented for hours on this and it's super frustrating...

async function getList1(db: ????, table: ????, selection: () => SelectedFields??) {
  const conditions = buildConditionsFromMagicalSource(table);
  const q1 = db.select({ count: count() }).from(table).where(and(...conditions));
  const q2 = db.select(selection()).from(table).where(and(...conditions));
  const [r1, r2] = await Promise.all(q1, q2);
  return { total: r1.count, items: r2 };
}
const try1 = await getList1(mainDb, my_table, publicRow);

// I considered using the drizzle way for this, but it does not result
// in a single function that I can reuse to paginate lists

function getList2(qb: PgSelect) {
  const conditions = buildConditionsFromMagicalSource(table);
  // Can't formulate or run a 2nd query here without passing db and table,
  // so I might as well aim for getList1 style...
  return qb.where(and(...conditions));
}
const try2 = await getList2(   mainDb.select(publicRow()).from(my_table)    );

// I much prefer getList1 call syntax though 
// AND PgSelect requires a call to $dynamic() 
// which apparently does nothing for me

IMO ORM / query builders should all strive to make this exact scenario as easy and streamlined as possible.

A set of 5 or so functions like this can do all the work for hundreds of tables in an application.

EDIT:

[EXPAND] Here's the best I could do for a simpler operation called getMany:

/** @file Resource helpers for implementing JSON Server. */
import { type SelectedFields, and, eq, inArray, isNull } from "drizzle-orm";
import { type SelectResult } from "drizzle-orm/query-builders/select.types";
import {
  type AnyPgColumn,
  type PgColumn,
  type PgTable,
} from "drizzle-orm/pg-core";
import { type NeonHttpDatabase as DbClient } from "drizzle-orm/neon-http";
import { ListOptions } from "./my/own/code";

/** Selects rows matching an array of ids or a single id. */
export async function getMany<
  D extends DbClient,
  T extends PgTable &
    ({ id: AnyPgColumn } | { id: AnyPgColumn; deleted_at: AnyPgColumn }),
  S extends () => SelectedFields<PgColumn, PgTable>,
>(db: D, table: T, selection: S, options: Required<Pick<ListOptions, "id">>) {
  const { id } = options;
  const conditions: Parameters<typeof and> = [];
  if (Array.isArray(id)) {
    conditions.push(inArray(table.id, id));
  } else {
    conditions.push(eq(table.id, id));
  }
  if ("deleted_at" in table && table.deleted_at) {
    conditions.push(isNull(table.deleted_at));
  }
  const items = (await db
    .select(selection())
    .from(table as any)
    .where(and(...conditions))) as SelectResult<ReturnType<S>, "single", {}>[];
  const total = items.length;
  return {
    total,
    items,
  };
}

So, we're leaning on 2 casts, for:

• .from(table as any)
• (await db...) as SelectResult<ReturnType<S>, "single", {}>[]

The first is to bypass a type error and the 2nd is to return the correct result type. This is not terrible and it's a pretty good middle ground candidate that I'll be testing.

[gshpychka]

@AndriiSherman please - you've gotta be more active with responding to people's issues. I get that you're working in your isolated branch, but it really doesn't help the vibe that the project is somewhat dead. The "releases" page on the website is still outdated. It was actually the first thing that made me have doubts about the project's health, which brought me to this issue. Your response makes sense and was reassuring, but since then I've seen so many seemingly important issues with no acknowledgement from the team, etc - it is pretty demoralizing.

[KazimirPodolski]

We’re now a team of 15 developers working full-time on Drizzle.

Excuse me sir, but I have to ask where are those 15 developers? Definitely not on Github. That's A LOT of developers and the impact will definitely be shown.

[waynesbrain]

Looks like the main guys are all in the Ukraine if you follow their twitter links on the top left - https://drizzle.team/

Not sure if that affects things but beyond that, it looks like they're working on their commercial offering - https://gateway.drizzle.team/

I hope they make lots of money! They will be getting some of mine for sure as soon as I make a dollar and a cent off of a one project that I use drizzle on.

[waynesbrain]

@KazimirPodolski Also waddler https://github.com/drizzle-team/waddler/commits/main/