[thatwasunusual]

Great work!

But why would anyone use an ORM that is specifically to one database? For me, using an ORM is the ability to switch between databases, specifically SQLite for testing and PostgreSQL for production, without having to change any logic.

[lroal]

You should try https://github.com/alfateam/rdb

It is database agnostic. It works with sqlite, mssql, mysql, postgres, oracle, and sapase.

It gives you full intellisense without code generation - even when running pure javascript.

You can run it from the browser in a secure manner, as you can host it in express js via adapter.

I am the author.

[dumbo-octopus]

Curious how that works? Do you not use any features of Postgres that aren't present in SQLLite? If so, why not just SQLite everywhere? Alternatively, why not spin up an ephemeral PG container for testing? Seems odd to not practice how you play to that extent.

[lupusreal]

It virtually never works. ORMs letting you change databases is something ORM proponents like to suggest but very rarely does it work without a ton of work (nullifying the point.)

[thatwasunusual]

I have been DB-agnostic for 20 years, and it has never been a problem, except when I meet ORMs or "SQL-based solutions" (usually procedures and/or views) that are specific to one database.

Luckily, I'm in a position where I can choose for our clients, so... :)

[basil-rash]

Oh I see MySQL added functional indexing in 8.0.13, that’s the main thing I would miss from Postgres. Partial indexes are also nice to have, but I suppose a sophisticated enough ORM could map them to functional ones, at least in so far as testing is concerned. The memory use would likely be much higher than a proper partial index.

[thatwasunusual]

> Oh I see MySQL added functional indexing in 8.0.13, [...]

We're talking about agonostic ORMs, not specific benefits for each of the databases.

I wish there were an SQL standard. But, the best part of standards is that there are so many of them. :(

[basil-rash]

Oh I was thinking of ORMs like Prisma, where the single ORM System is responsible for both runtime mapping of objects to relations, and development/deployment time provisioning of schemas, migrations, indexes, etc.

[thatwasunusual]

I prefer to only use ORMs that can be used "everywhere." PostgreSQL needs to be used on production for performance; SQLite is good, but not _that_ good :), but it's perfect for testing things locally.