SynapCores
Install free

SynapCores

SynapCores v2.3.3 — Date math you can trust, and external Parquet that stops fighting you

Published on October 26, 2026

SynapCores Community Edition v2.3.3-ce

Community Edition · free · seamless upgrade from v2.3.x

Date math you can trust, and external Parquet that stops fighting your schema — a correctness release that makes the SQL you already write return the right answer.

A correctness release isn't a feature parade, and that's the point. The headline fix here is the kind of bug that doesn't throw an error — it just quietly returns the wrong rows. If you've ever written WHERE created_at < CURRENT_DATE - INTERVAL '2' YEAR for a retention report, this release matters to you.

New in v2.3.3

1. Calendar date arithmetic is correct

Outcome: your time-windowed analytics return the right rows.

Before v2.3.3, every INTERVAL was reduced to an approximate integer number of days, and a YEAR/MONTH field suffix was ignored outright — so CURRENT_DATE - INTERVAL '10' YEAR quietly behaved like minus ten days, and sub-day intervals were dropped to zero. No error; just a wrong answer in any year- or month-windowed query.

Now it does real calendar arithmetic:

SELECT DATE '2026-10-24' - INTERVAL '10' YEAR;    -- 2016-10-24  (not "ten days ago")
SELECT DATE '2024-03-31' - INTERVAL '1'  MONTH;   -- 2024-02-29  (leap-aware, clamps to month end)
SELECT DATE '2026-10-24' + INTERVAL '1.5 hours';  -- 2026-10-24 01:30:00  (sub-day precision kept)
  • YEAR / MONTH count leap years and clamp to the last valid day of the destination month.
  • Fixed-duration units (WEEK/DAY/HOUR/MINUTE/SECOND, down to nanoseconds) keep exact precision.
  • CAST(value AS DATE) is strictly validated in SELECT, filters, and INSERT … VALUES — NULL propagates, and invalid dates, times or trailing junk return an error instead of passing silently.
  • Unknown or contradictory units, and YEAR TO MONTH ranges, now error — they are never silently approximated.

2. External Parquet that tolerates real-world schemas

Outcome: third-party Parquet datasets that evolve keep reading.

Data lakes drift. v2.3.3 makes reads over foreign Parquet resilient to the schema changes you actually hit:

  • Nullability-only differences reconcile — files that disagree on REQUIRED vs OPTIONAL for the same column widen to nullable instead of failing the read.
  • Additive columns union by name — a file written before a column existed simply reads that column as a typed NULL; REFRESH surfaces newly added columns on an inferred table.
  • An authorized empty location can register with a declared schema and return zero rows, then light up as the first files land.
  • Errors now name the offending file and column, with both the type and nullability in the message.

3. NULL-safe scalar math and honest boolean evaluation

Outcome: aggregates over sparse data stop erroring, and logic short-circuits.

  • SQRT(NULL), POWER(NULL, 2) and POWER(2, NULL) return NULL (they used to error), and both accept exact DECIMAL inputs.
  • FALSE AND … / TRUE OR … short-circuit the right-hand side, with the three-valued (UNKNOWN) truth tables preserved.
  • ORDER BY on a computed alias is stable even when a scan returns no rows or all-NULL values — the derived column keeps its type across batches.

4. Two engine-stability fixes, caught by validating the shipping build

Outcome: the engine stays up on query shapes that pushed its limits.

We validate the actual release artifact, not a debug build — and that caught two crashes a debug build had hidden:

  • A common-table expression whose body returned zero rows recorded no schema, failing with CTE '…' schema not found. It now derives a schema from the CTE's own columns.
  • A view body now executes on a fresh task, and the request worker stack was enlarged, so a cross-database RENAME with a dependent view — and deeply nested join/aggregate/CTE plans — no longer risk a worker-stack overflow.

Proof

Validated on the shipping artifact on a non-AVX-512 CPU: the state-asserting feature validator passes 316 / 0; the recipe certification sweep is 177 / 187 with zero regressions against v2.3.2 (the ten not-certified recipes fail identically on v2.3.2 and need external infrastructure); the runtime canary boots and runs a model with no SIGILL; and a matched-build A/B shows no query-speed regression. Platform-complete: linux-x86_64, linux-aarch64, darwin-aarch64.

Honest boundaries

  • Exact DECIMAL values are still returned as JSON strings to preserve full precision — an explicit CAST(… AS DOUBLE) gives you a numeric JSON value. Changing the default would risk silently rounding money.
  • Dates, timestamps and intervals use the engine's ISO-text representation; this release does not add a persisted DATE or INTERVAL column type.
  • With the pinned SQL parser, an inline interval on the left of arithmetic needs parentheses — (INTERVAL '2 weeks') + DATE '2024-02-20' — or use the suffix form INTERVAL '2' WEEK.
  • Foreign-Parquet NULL synthesis and schema union apply to external tables only; managed datasets keep their verified-manifest read path.

Upgrade

curl -fsSL https://get.synapcores.com | sh        # installs the latest (v2.3.3-ce)
docker pull synapcores/community:v2.3.3-ce         # or pin

Community Edition, free. Seamless upgrade from v2.3.x — no on-disk format change. Full technical notes live in the v2.3.3-ce release page.