Great summary where we are at with types, Patrick.
It is nice to see it like that.
I think the situation on the type front might be way better.
Supporting e.g macaddr/8 seems like a programming exercise.
Also since we have constraints as well, some constructs like enums
might be done quite easily too. e.g. like
myname text check in('black', 'white')
I think it is possible to do IN in PostgreSQL like this
colors TEXT CHECK (colors IN ('red', 'green', 'blue'))
I think that is pretty close to our constraints if IN is supported
there too. The current constraints implementation we have already
supports adding arguments into constraint function so this can be
implemented right away without anything else.
we do not need to have enum types (1). Or maybe we could, really up to
us how we model it, but if there is already a constraint framework
making it possible I do not think that introducing enum types just for
the sake of PostgreSQL compatibility is really necessary.
(1) https://www.postgresql.org/docs/current/datatype-enum.html
For types like "real" in Postgres and float in Cassandra, it seems
like it is the same thing, so maybe we might create an alias of "real"
in Cassandra as well?
JSON / JSONB / XML - this is an interesting idea, there was already
some discussion about this when we were introducing JSON constraints.
I am not against the introduction of JSON / XML type, they would be
validated on insert. Another discussion thread to have :)
Overall, when it comes to types at least, I think that the situation
might be way better and might be more compatible for sure.
On Fri, Oct 31, 2025 at 9:25 PM Patrick McFadin <[email protected]> wrote:
>
> Over the last decade, CQL has served Cassandra users well by offering a
> familiar SQL-like interface for a distributed data model. However, as the
> broader database ecosystem converges on PostgreSQL-style SQL as the de facto
> standard for developers, it’s time to consider how Cassandra evolves to meet
> developers where they are without losing what makes it unique.
>
> The great thing about SQL standards is that there are plenty to choose from.
> While the formal SQL:2023 specification (ISO/IEC 9075) exists, the industry
> has coalesced around the PostgreSQL dialect. Products such as AWS Aurora,
> AlloyDB, CockroachDB, YugabyteDB, and DuckDB, and many others offering
> “PostgreSQL-compatible” modes, have validated this direction. Developers are
> voting with their implementations. PostgreSQL SQL represents the lowest
> cognitive-load interface for application data, as repeatedly confirmed by
> developer surveys like Stack Overflow 2025[1].
>
> What I’m proposing is that we begin to normalize the frontend to expand
> access to our extraordinary backend. The key principle here is ADD, not
> DELETE. CQL continues to work and be supported while we expand Cassandra’s
> capabilities through SQL compatibility, providing a familiar syntax and
> potentially supporting a larger ecosystem (JDBC, etc.).
>
> Phase 1 (Before Cassandra 6) - Stop Digging
> Freeze CQL at version 3 and align all new syntax or features (DML/DDL) to the
> PostgreSQL SQL dialect wherever possible. This approach was already
> demonstrated with CEP-52 and should become our norm.
>
> Phase 2 (Years) - Create Parallel Paths
> This is where we take our time and do things carefully, most likely over a
> series of years. Don’t touch the CQL path. Add an opt-in, feature flag path
> for SQL-only that conforms to the PostgreSQL SQL dialect. Begin our journey
> to feature compatibility here. At Community over Code this year, Alex Petrov
> and I sat in Aaron Ploetz’s kitchen (thanks for dinner, Aaron!) and
> brainstormed how this could work. The two critical aspects to manage are
> types and functionality. We may never be able to support everything, but
> given what this project has accomplished over the years, I wouldn’t bet on
> it. Being clear about the differences early on can serve as a roadmap for
> future contributors who want to be involved.
>
> In discussion with Joel Shepherd on this topic, he sagely suggested some
> sub-steps inside this phase:
>
> 1 - Prioritize SQL that is compatible to get the incremental wins and early
> feedback from the user community.
> 2 - Tackle the non-compatible and triage for the long-term changes that would
> need to happen.
> I took the time to do some rough mapping of syntax, features, and types:
>
> Function and Feature Compatibility tables:
> https://docs.google.com/document/d/1K2-GKVM4Z_u1Hb1GtdrRyC9AdDN3RLwJ7LX_i_PqkOE/edit?usp=sharing
>
> Typing differences:
> https://docs.google.com/spreadsheets/d/11tWkyCQ8WAFGnd5Va6iyltkp1wbKdAubxH9o_ZyJEtk/edit?usp=sharing
>
> Phase 3 (Indefinite timeframe)– Become Default SQL
> Once the SQL path achieves sufficient coverage and confidence, we can make it
> the default frontend, with CQL continuing to be supported indefinitely. The
> intent is not replacement but evolution toward broader accessibility.
>
> This proposal is an invitation for discussion. Feedback from contributors,
> driver maintainers, and downstream users will guide the roadmap and
> priorities. The result will be the creation of CEPs as needed. If we get this
> right, Cassandra’s next decade will be defined by reach, compatibility, and
> continued excellence in scalability.
>
> If you saw my talk in Minneapolis[2], you know I've been thinking about what
> we can accomplish in 10 years. The Phase 1 piece is near-term, but no
> timeframe for everything else. The best consensus I can hope for today is on
> directionality, and that starts with phase 1.
>
> Patrick
>
> 1 -
> https://survey.stackoverflow.co/2025/technology#most-popular-technologies-database-prof
> 2 - https://youtu.be/rIh968dSlkQ
