You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In JS, we have two different oddballs null and undefined. In SQL, they are represented as NULL.
Inserting them to database makes them coerced to NULL; however selecting to JS realm always produces nulls, which is not always desirable.
What is the feature you are proposing to solve the problem?
Similarly to statement.setReadBigInts(enabled), we can have statement.setReadNullAsUndefined() to make reads return NULLs as undefined instead of null.
Honestly, this would be a good feature and I've run into a couple of cases where I have to convert SQL null types by hand. I've opened a pull request with the change: #59462.
If it gets approved there could be a database-wide option after. But this one only implements setReadNullAsUndefined() on statements.
When does getting null instead of undefined matter?
Most notably, whenever we serialize the data to store or send. In JSON, every null consumes space, increases parsing time, reduces readability.
Web API, especially having databases with sparse columns, usually should prefer not sending nulls to avoid wasting traffic.
Also this is semantically more correct behaviour when we expect business logic to add new columns that are sparse by design and should not affect previously inserted rows. hasDiscountOnApril2010Promo, bonusAttackDuring1252Event, isAiGenerated, showSpecialWarningPopup, extraParams, and other stuff that inevitably happens someday.
What I saw from these links is people complaining about typing (where they'd like to use something like myprop?: string). The MongoDB link is about a migration from undefined to null.
The players I brought are more similar to what node:sqlite is.
Are any other libraries actually implementing something like this? I think it's good to differentiate between feature requests and actual implementations.
That said, I'm not opposed to this as long as it doesn't break anything. I also think it's worth benchmarking since SQLITE_VALUE_TO_JS() is likely a pretty hot path, and taking a performance hit there wouldn't be a good idea for a feature that no other libraries ship.
I consider applications should use pattern like DTO to return data to external services / users.
It's a good practice to avoid returning unwanted or sensible data. Also decoupling raw data from data-source to data-view allow easy switch from one data-source to another one, explicit interface for aggregation and so on.
I think a low level API like node:sqlite should not have the responsibility to transform data. This kind of transformation should be done at higher level like ORM layer or Data view layer.
Reacted by Edy Silva, humarkx and Miguel Marcondes Filho
This issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
Activity
bakkot commentedon Aug 13, 2025
When does getting null instead of undefined matter?
jac0bandres commentedon Aug 13, 2025
Honestly, this would be a good feature and I've run into a couple of cases where I have to convert SQL null types by hand. I've opened a pull request with the change: #59462.
If it gets approved there could be a database-wide option after. But this one only implements setReadNullAsUndefined() on statements.
LiviaMedeiros commentedon Aug 14, 2025
Most notably, whenever we serialize the data to store or send. In JSON, every
nullconsumes space, increases parsing time, reduces readability.Web API, especially having databases with sparse columns, usually should prefer not sending
nulls to avoid wasting traffic.Also this is semantically more correct behaviour when we expect business logic to add new columns that are sparse by design and should not affect previously inserted rows.
hasDiscountOnApril2010Promo,bonusAttackDuring1252Event,isAiGenerated,showSpecialWarningPopup,extraParams, and other stuff that inevitably happens someday.geeksilva97 commentedon Aug 14, 2025
Is there any use case for this? In which situation does an
undefinedbehave in a way that, withnull, it would be a problem?I was looking into other players, and it's just a
null.jac0bandres commentedon Aug 14, 2025
Besides the use cases we've laid out in this issue and the PR discussion, here are some more sources:
Drizzle ORM request for distinct
nullandundefinedhandling: drizzle-team/drizzle-orm#2745Another for Supabase: supabase/supabase-js#244
MongoDB distinction between the types and their use cases: https://www.mongodb.com/docs/manual/reference/bson-types/migrate-undefined/
geeksilva97 commentedon Aug 18, 2025
Thank you for the references.
What I saw from these links is people complaining about typing (where they'd like to use something like
myprop?: string). The MongoDB link is about a migration fromundefinedtonull.The players I brought are more similar to what
node:sqliteis.geeksilva97 commentedon Aug 18, 2025
Would you have an opinion here @cjihrig @nodejs/sqlite ?
cjihrig commentedon Aug 18, 2025
Are any other libraries actually implementing something like this? I think it's good to differentiate between feature requests and actual implementations.
That said, I'm not opposed to this as long as it doesn't break anything. I also think it's worth benchmarking since
SQLITE_VALUE_TO_JS()is likely a pretty hot path, and taking a performance hit there wouldn't be a good idea for a feature that no other libraries ship.louwers commentedon Aug 18, 2025
People really seem passionate about wanting
undefinedto be returned instead ofnull. I can see the appeal if you want to serialize to JSON.Interesting idea. API seems consistent. Not very complex to implement. Why not!
tpoisseau commentedon Aug 25, 2025
I consider applications should use pattern like DTO to return data to external services / users.
It's a good practice to avoid returning unwanted or sensible data. Also decoupling raw data from data-source to data-view allow easy switch from one data-source to another one, explicit interface for aggregation and so on.
I think a low level API like
node:sqliteshould not have the responsibility to transform data. This kind of transformation should be done at higher level like ORM layer or Data view layer.mattskel commentedon Jan 22, 2026
@LiviaMedeiros @cjihrig I’ve put together a draft PR that adds statement-level support for reading SQL NULL values as undefined.
If you’re happy with the approach, I’m happy to continue and add the relevant tests.
geeksilva97 commentedon Jan 23, 2026
Bun has the same behavior: https://bun.com/docs/runtime/sqlite
mike-git374 commentedon Feb 14, 2026
Note that after db.prepare(sql, options) was added these options like
readNullAsUndefinedshould be added todb.prepare(sql, options)and new DatabaseSync(path, options) as thestatement.set*functions may be deprecated.I see 2 PR's open for this issue but neither have correctly added the options: #61472 #59462
sqlite: add support for reading NULL as undefined
github-actions commentedon Jul 20, 2026
This issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.