We lost the habit of putting everything here but we still have many great features that have been merged recently and a few very big ones coming soon.
semi-breaking change in Postgres TIMESTAMP return
However, want to take the opportunity to warn about a semi breaking change in the way our native Postgres runtime return TIMESTAMP . it used to be in this format:
"2026-05-08 17:54:03.348891 UTC" .
but they are have been standardized to (ISO 8601): "2026-05-08T17:54:03.348891+00:00" in recent releases. If you relied critically on the specific format, be advised you will need to adapt to this change.
It was mistakenly in the UTC format prior which is non standard, not consistent with pg behavior and not even consistent with what format taken as input by our pg runtime as valid TIMESTAMP.
Sorry about this, we realized a bit late that by doing a batch of runtime improvement on pg, it induced this change and it's now too late to revert or make fully back-compatible.
semi-breaking change in Postgres TIMESTAMP returnHowever, want to take the opportunity to warn about a semi breaking change in the way our native Postgres runtime return TIMESTAMP . it used to be in this format:
"2026-05-08 17:54:03.348891 UTC" .
but they are have been standardized to (ISO 8601): "2026-05-08T17:54:03.348891+00:00" in recent releases. If you relied critically on the specific format, be advised you will need to adapt to this change.
It was mistakenly in the UTC format prior which is non standard, not consistent with pg behavior and not even consistent with what format taken as input by our pg runtime as valid TIMESTAMP.
Sorry about this, we realized a bit late that by doing a batch of runtime improvement on pg, it induced this change and it's now too late to revert or make fully back-compatible.
