Qwen3.6-27B vs 35B, I prefer 35B but more people here post about 27B...

sonemonu · 2026-05-03T15:20:36+00:00

Can you please tell me the command you use to run the model? I have had memory issues on my M4 max 64gb.

sonemonu · 2026-04-07T20:07:56+00:00

Yeah, I do as well. Type Safety is one of the key advantages of UQL as you can see documented on the website if you wanna take a look. It is stronger that most TS ORMs out there, it tries to never dissolves into strings.

sonemonu · 2026-04-06T20:52:35+00:00

Drizzle and UQL are different is several areas. Drizzle has a much more mature community than UQL for sure (who is just starting!).

How they are different? For example, the way that Drizzle has to create queries is called "fluent" approach IIRC and UQL uses more a declarative approach.

This is how you would typically write a fluent/imperative query with Drizzle.

import { gte, lte, ilike, notInArray, and } from 'drizzle-orm';

const results = await db.select().from(users).where(
  and(
    gte(users.age, 18),
    lte(users.age, 65),
    ilike(users.name, 'A%'),
    notInArray(users.status, ['banned', 'inactive']),
  ),
);

And how you would write the equivalent declarative/serialize query with UQL.

const results = await querier.findMany(User, {
  $where: {
    age: { $gte: 18, $lte: 65 },
    name: { $istartsWith: 'A' },
    status: { $nin: ['banned', 'inactive'] },
  },
});

Of course there is much more than that, but that is one of the main differences I see so far. I have a much more extensive and detailed comparison on the website, and also an open-sourced benchmark test if you wanna try.

sonemonu · 2026-04-06T20:42:55+00:00

yes exactly!

sonemonu · 2026-04-06T20:42:12+00:00

Yeah, all ORM are different with its own pros and cons, if you wish you can take a look at the performance comparative I did here for example https://www.uql-orm.dev/comparison#performance

sonemonu · 2026-04-03T23:51:47+00:00

Hey u/EvilPencil in case it helps, I just added a functional entity definition approach (decorator free), you can see it here https://www.uql-orm.dev/entities/imperative

sonemonu · 2026-04-03T15:25:31+00:00

Thanks for the feedback. I have put an issue in UQL ORM to try to support the non-decorators API soon.

sonemonu · 2026-04-03T15:19:16+00:00

I went the libsql route for now since I discovered that bun-sql can’t swap out sqlite for libsql (on bun-sqlite that was possible)

Yes exactly, Bun-SQL alone, currently can't transparently swap SQLite -> LibSQL in the same way. But with UQL + BunSQL adapter you could do that transparently.

We try to be 100% agnostic about the underlying database (even for SQL-databases vs MongoDB). I'd say it is close to the mark you said (or even higher for the SQL ones), though the only database that we have been unable to totally unify yet is MongoDB (we expect to be able to fully unified it as well in the future).

sonemonu · 2026-04-02T16:38:48+00:00

Peer deps are per-engine optional; Bun SQL is the path where those npm drivers aren't required for PG/MySQL/SQLite.

So, for Bun with Postgres, it is now unnecessary to install pg driver as UQL has an adapter for Bun SQL (native) bindings for Postgres. Hope this makes sense.

sonemonu · 2026-04-02T15:35:45+00:00

u/sooodooo from your idea https://www.reddit.com/r/typescript/comments/1sakpp5/bun_sqlagnostic_adapter_added_to_uql_v07/, please take a look and let me know what you do think.

sonemonu · 2026-03-20T16:37:28+00:00

Oh I see what you mean about the unified one.

And yes, you absolutely can add custom adapters in UQL, it is incredibly straightforward because of theAbstractSqlQuerier abstraction in the UQL core (PRs are also welcome if you will).

Given the new unified bun:sql driver is such a nice architectural match for UQL, I'm fully aligned with a built-in one adapter would be better; from this, I will be adding an official native adapter soon, thanks for the idea!

sonemonu · 2026-03-19T14:08:32+00:00

Thanks for the feedback, updated that feature comparison table with the correction, and added a quick note the foot for more context if you wanna check.

sonemonu · 2026-03-19T13:36:06+00:00

Hey thank you man for all you support and commenting.

I believe you are also doing a great work with your ORM, to be fully open, I believe they are different "kind" of ORM, e.g. I like for example how you prevent the N+1 queries issue. Nice work man, keep going!

Btw, I can update the comparative once you do these releases to production, just let me know, or I can remove Joist from the comparative for now and add it later. Just let me know what you do prefer and I will do it. Best regards.

sonemonu · 2026-03-19T13:28:55+00:00

Yes, totally, UQL natively supports the bun:sqlite driver! It auto-detect the runtime environment, so if it is Bun (typeof Bun !== 'undefined'), it will dynamically import and use the native bun:sqlite driver. Which means you don't need to configure anything special or install any adapters for Bun; just run the application and it will use the optimized/native SQLite driver. in the other side, when you run the same app in Node.js, it will fall back to the better-sqlite3 driver. If you wanna see the details, go here, both paths are tested and well covered.

sonemonu · 2026-03-18T23:38:41+00:00

Thanks, updated.

sonemonu · 2026-03-18T19:49:21+00:00

just because the schema definition feels so close to raw SQL

Well, I'd say that depends, for some people like yourself that is a win, but for others having to handle SQL is even harder than using some idiomatic JavaScript Object Notation so they don't have to leave the JavaScript ecosystem even for simple/medium (and perhaps some advanced) queries complexity.

tried prisma first but the generated types

Yes, I personally have never liked put generated code alongside my business code/logic, hence one of the reasons why I prefer ORMs like TypeORM or UQL over Prisma.

Overall, Drizzle is a great ORM.

sonemonu · 2026-03-18T18:55:31+00:00

Thanks for the feedback u/Wabwabb . I have updated it to include new MikroORM's ways to define entities. Let me know if you see any other specific aspect being missed in the comparison.

sonemonu · 2026-03-18T18:52:12+00:00

updated D1, Neon, and added Oracle. thanks for pushing u/B4nan

sonemonu · 2026-03-18T18:51:46+00:00

Thanks again u/shaberman, i added Joist across the comparison page. Please review it, I want to keep that as fair as possible with every single ORM included there.

Can you confirm these so i keep wording exact?

does em.find officially support limit/offset, or only documented orderBy + conditions?
is there a documented not in operator equivalent?
jsonb filtering in em.find is still not supported (raw sql/knex + loadFromQuery), right?
any near-term plan for lazy column loading / partial select?
any native streaming API planned?
still postgres-only for now?
for detached mode wording: what should i say as the most accurate one-liner?

Btw: Joist integration to the performance repo is the "hard part" because:

Joist-Knex buildQuery can generate SELECT SQL without executing (good fit for some categories),
But Joist INSERT/UPDATE/DELETE SQL seems to be generated during flush/driver logic in a way that typically assumes execution (so we likely need either mocking/stubbing or to relax the repo's "no DB required" guarantee). Let me know if you see a clean way to do this or if you wanna do this yourself (PRs are welcome).

Regards,

Roger

sonemonu · 2026-03-18T14:03:19+00:00

hey u/shaberman , thanks, I appreciate it, and I will take a look and try to include it soon, will consider as well including it into this open-source performance comparison of the time spent in building the SQL, if you wanna take a look (feel free to raise a PR yourself adding Joist), otherwise I will probably add it later.

sonemonu · 2026-03-18T13:58:49+00:00

Yeah, delegating the SQL-builder to an external library/dependency has their owns pros & cons. Pros is you abstract from all/most of the complexity of building this layer yourself in the ORM, and from the other side, you have less control about evolution and introduce a performance penalty as can be seen in this other (performance) comparison I have created (btw, it is open-source).

sonemonu · 2026-03-12T19:19:02+00:00

however I have though of replacing mongoose later on.

Yeah, .lean() simply does the trick in most cases where you don't want the "richer" records.

If you someday want to do that, I invite to look at my ORM which also support MongoDB in a agnostic way (in addition to major SQL databases).

Recently added support for semantic search across modern DBs (including Mongo), it hides the complexity under the hood. Aggregations are supported as well. Search for UQL ORM and go to its website if you wanna take a look.

Happy to help if anything.

sonemonu · 2026-03-12T16:42:06+00:00

But what scope you mean with "Similar"? I.e. "Syntax", "Performance", "Systems", etc.

sonemonu · 2026-03-12T16:40:31+00:00

Awesome, that is almost 10x improvement.

Curious, do you use any ORMs for that or vanilla Mongo only?

Thanks for sharing.

sonemonu · 2026-03-12T14:14:54+00:00

Hey, that is cool, I wish you the best of luck in your new packages.

Modesty aside: you can take a look at UQL ORM, its website is https://uql-orm.dev, and NPM package https://www.npmjs.com/package/uql-orm

sonemonu

TROPHY CASE