Re: [DISCUSS] SQL support in Cassandra

Just responding to one point among many good ones, below ... On 11/5/2025 10:29 AM, David Capwell wrote: SQL has been building its surface area for decades and trying to catch up is a significant effort and how to make things correct and performant becomes an issue.  In the latest spec there is

Re: [DISCUSS] SQL support in Cassandra

A bit late to this convo but I generally support the POV Joey and Chris shared. I think SQL can be interesting as a separate layer. Stepping back I think there is a larger conversation: the initial email implicitly positions Cassandra’s succcess as trying to compete directly with Aurora/CRDB/etc o

Re: [DISCUSS] SQL support in Cassandra

I agree on splitting this up. I'll do that today. Patrick On Wed, Nov 5, 2025 at 10:44 AM Dinesh Joshi wrote: > There are two distinct conversations in this thread. > > 1. What does the evolution of CQL Syntax look like? > 2. What is the path to bring SQL to Cassandra? > > I suggest we fork 2 d

Re: [DISCUSS] SQL support in Cassandra

There are two distinct conversations in this thread. 1. What does the evolution of CQL Syntax look like? 2. What is the path to bring SQL to Cassandra? I suggest we fork 2 discuss threads to have a focused discussion on each topic. Thanks, Dinesh On Wed, Nov 5, 2025 at 10:29 AM David Capwell

Re: [DISCUSS] SQL support in Cassandra

My personal stance is that new work should look at existing syntax and ask the question “why are we different”, if the answer is “I prefer this” or “I didn’t have the time”, I want to push back against this and argue for SQL / Postgres w/e possible. If the answer is “correctness” or “performanc

Re: [DISCUSS] SQL support in Cassandra

My intuition is that we would still compare quite favorably to almost all other API ecosystems even w/a routing layer gap, our core strength being a clean, horizontally scaling, partitioned data store. If we introduced a 1-3ms overhead (shooting for an artificially high # here) from using API ->

Re: [DISCUSS] SQL support in Cassandra

CQL just to demonstrate it’s possibleFat node style would indeed be faster but im mostly proving that its functionalOn Nov 5, 2025, at 8:55 AM, Joseph Lynch wrote:I very much like Jeff, Josh et al.'s proposals around the pluggable stateless API layer. Also I agree with Chris I would prefer a simp

Re: [DISCUSS] SQL support in Cassandra

I very much like Jeff, Josh et al.'s proposals around the pluggable stateless API layer. Also I agree with Chris I would prefer a simpler API not a more complex one for our applications to couple to e.g. the Java stdlib. This also sets up a really nice path where the community members can build the

Re: [DISCUSS] SQL support in Cassandra

> Again from Right. I'm just zooming out a bit more and applying that same logical pattern broadly to other API language domains, not just SQL. But yes - your point definitely stands. On Tue, Nov 4, 2025, at 6:42 PM, Patrick McFadin wrote: > I’m grooving on what “Cloud Native Jeff” is saying her

Re: [DISCUSS] SQL support in Cassandra

I’m grooving on what “Cloud Native Jeff” is saying here and I would like to see where this could go. If we use a well established library like Calcite, then there is no API to maintain. We might find parts of Cassandra along the way we could alter to make it easier to integrate, but so far that’

Re: [DISCUSS] SQL support in Cassandra

On 2025/11/04 22:32:08 Josh McKenzie wrote: > > So I guess what I'm noodling on here is a superset of what Patrick is w/a > slight modification, where we double down on CQL as being the "low level high > performance" API for C*, and have SQL and other APIs built on top of that. > Again from

Re: [DISCUSS] SQL support in Cassandra

> conforming to one of the "standard" data APIs could make more people more > comfortable with staking their future on Cassandra Aligning with a standard data API could make people more comfortable staking their future, and deprecating a 2nd primary query language would *definitely* make people

Re: [DISCUSS] SQL support in Cassandra

On 11/4/2025 11:42 AM, Patrick McFadin wrote: Just to be clear, in my initial proposal I said that CQL can never go away. It’s a life sentence. Knowing the upgrade cycle that many users are on, it will be 50 years before we could even try. Fifty years will go by like that. :-) I'd mostly wo

Re: [DISCUSS] SQL support in Cassandra

On 11/3/2025 10:38 PM, Mick wrote: On 3 Nov 2025, at 20:32, Joel Shepherd wrote: At the same time, my personal opinion is that if SQL compatibility is pursued, then the end game should be to deprecate CQL. That will probably take years, but at the limit I don't see a lot of benefit to supporti

Re: [DISCUSS] SQL support in Cassandra

Yes and I’m not asking for wholesale conversion. The few time we need to add new syntax, we default to established SQL syntax. Example where this was already done was in CEP-52 > On Nov 4, 2025, at 11:56 AM, Jeff Jirsa wrote: > > Conversion doesn't seem practical or desirable: it'd probably re

Re: [DISCUSS] SQL support in Cassandra

> It could also be that nobody's willing to actually do it for real, in which > case it's all talk and there's no decision to make. I know of at least 2 groups running thousands of C* clusters w/projects in front of them exposing different APIs than CQL so there's definitely people willing to d

Re: [DISCUSS] SQL support in Cassandra

On 2025/11/04 19:42:31 Patrick McFadin wrote: > Just to be clear, in my initial proposal I said that CQL can never go away. > It’s a life sentence. Knowing the upgrade cycle that many users are on, it > will be 50 years before we could even try. > > I feel we are at a fork here in the discus

Re: [DISCUSS] SQL support in Cassandra

When a user hears PostgreSQL compatibility, the implicit assumption they have is a full bug-for-bug compatibility with Postgres. I don't think that's what you mean here, is it? On Tue, Nov 4, 2025 at 11:38 AM Jeff Jirsa wrote: > I started building a Postgres layer to convince myself it’s possibl

Re: [DISCUSS] SQL support in Cassandra

Maybe a subproject? > On Nov 4, 2025, at 11:35 AM, Jeff Jirsa wrote: > > I don’t think the project needs to build this into cassandra. There are a lot > of reasons not to do that.

Re: [DISCUSS] SQL support in Cassandra

Just to be clear, in my initial proposal I said that CQL can never go away. It’s a life sentence. Knowing the upgrade cycle that many users are on, it will be 50 years before we could even try. I feel we are at a fork here in the discussion. Fork 1: Discuss and somehow ratify that we adhere t

Re: [DISCUSS] SQL support in Cassandra

I started building a Postgres layer to convince myself it’s possible. It’s got joins, interactive transactions, mvcc, pg wire protocol, query planner, etc. it’s far enough along I can run tpc-c. The only cassandra change that was needed was a fix to accord for BOP variable length tokens serialized

Re: [DISCUSS] SQL support in Cassandra

Good point Joey; I was rather focused on the ergonomics of implicit constraint that come with CQL vs. SQL and the gap we'd have to bridge to make a SQL-centric world have the same design language as CQL today. We can't afford to drop CQL at this point unless we had an overwhelmingly bullet-proo

Re: [DISCUSS] SQL support in Cassandra

Just throwing my 2 cents in. I'm probably in the unpopular camp of wanting to to move the other direction towards a grpc endpoint that is even more restrictive than cql. This is coming from a standpoint of needing to clean up after mistakes (application/modeling etc, not cassandra) than the standpo

Re: [DISCUSS] SQL support in Cassandra

I share Joey's opinions on this. Many features that resemble SQL (e.g., indexes, materialized views) come with caveats that stem from their implementation details rather than the query language itself. If we expose these same features through SQL as they are today, I think we'd risk setting users u

Re: [DISCUSS] SQL support in Cassandra

I would be curious to see a gap analysis between CQL and SQL that include the differences in behaviors. I suspect that it will bring a few surprises and provide some more solid foundation to this discussion. Le mar. 4 nov. 2025 à 17:24, Štefan Miklošovič a écrit : > I just want to ask this quest

Re: [DISCUSS] SQL support in Cassandra

I just want to ask this question ... feel free to shoot it down, just curious about the feedback / pros / cons. When we talk about "joins", yeah, it is not supported as we are used to in the SQL world. But joins _are_ possible, via Spark (Cassandra connector) / via Spark itself. When we have Cass

Re: [DISCUSS] SQL support in Cassandra

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 easil

Re: [DISCUSS] SQL support in Cassandra

Overall I like this idea. It will help us lower the learning curve for Cassandra, making it feel like a more viable option for folks who might not otherwise have considered it. Keeping CQL and SQL as parallel options is the approach that I would prefer, as well. Might not be a bad idea to classify

Re: [DISCUSS] SQL support in Cassandra

Removing CQL is, in my opinion, completely off the table. When we deprecated Thrift and gave CQL as the new query language, we imposed significant pain on our existing functional Thrift applications to migrate to it - I feel we should not hurt our users like that again. I worry that we already str

Re: [DISCUSS] SQL support in Cassandra

I remember we had an in-depth discussion with Patrick after his talk in Minneapolis, where I raised my concern about pursuing full PostgreSQL compatibility, particularly considering the mindset shift it requires and the fact that Cassandra doesn’t support joins. While I understand the team’s direc

Re: [DISCUSS] SQL support in Cassandra

I’m sorta confused. You can do single table design in sql if you don’t have a join centric workload. You still get to tell the database how to order your data on disk.BOP gives you efficient range scans  without having partition size problems that trap users when they cross into mega partition trap

Re: [DISCUSS] SQL support in Cassandra

+1 to Mick and Aleksey. I think the key for me was this: > One is Cassandra’s wide-partition model with flexible clustering columns, > which supports very large, ordered partitions (e.g. time-series and efficient > range scans), rather than a strictly normalised, join-centric model. These > patt

Re: [DISCUSS] SQL support in Cassandra

I don’t mind us implementing some Postgres syntax support in some capacity, but I do not like the idea of limiting what Cassandra is allowed to do, or expose via CQL, to what is expressible by Postgres’s SQL. Many moons ago, before we started work on native protocol and CQL, I could perhaps a b

Re: [DISCUSS] SQL support in Cassandra

> On 3 Nov 2025, at 20:32, Joel Shepherd wrote: > > At the same time, my personal opinion is that if SQL compatibility is > pursued, then the end game should be to deprecate CQL. That will probably > take years, but at the limit I don't see a lot of benefit to supporting both. We want SQL

Re: [DISCUSS] SQL support in Cassandra

+1 I support this initiative. Also, I agree with the points raised by Joel. - We should deprecate CQL in the long term over SQL. - Cassandra engine is not optimized with all the SQL features, such as joins, so we should disable those features. - I view this initiative as a way to slow

Re: [DISCUSS] SQL support in Cassandra

On 11/1/2025 9:32 AM, Dinesh Joshi wrote: On Fri, Oct 31, 2025 at 5:00 PM Patrick McFadin wrote: Jeff and Dinesh jumped into Phase 2, which is really the fun and interesting part. To be clear, I am not proposing we make any changes pre Cassandra 6 in this case. And this will be

Re: [DISCUSS] SQL support in Cassandra

On Fri, Oct 31, 2025 at 5:00 PM Patrick McFadin wrote: > > Jeff and Dinesh jumped into Phase 2, which is really the fun and > interesting part. To be clear, I am not proposing we make any changes pre > Cassandra 6 in this case. And this will be a CEP or two or three. > I was not intentionally tr

Re: [DISCUSS] SQL support in Cassandra

You canBut you can also build that same layer stateless right now and not worry about trying to contain the cql’isms which expose the clustering concepts On Nov 1, 2025, at 8:04 AM, Patrick McFadin wrote:This opens up an entire line of discussion about the bigger goal of Cassandra becoming a full

Re: [DISCUSS] SQL support in Cassandra

This opens up an entire line of discussion about the bigger goal of Cassandra becoming a fully cloud native DB but I’m here for it. I’m not going to disagree with Jeff’s point. There is prior art that shows this is a way forward. What the DataStax team did splitting up parts of Cassandra to de

Re: [DISCUSS] SQL support in Cassandra

Jeff’s thoughts are mine exactly, and how I would imagine building this.– Scott—MobileOn Oct 31, 2025, at 9:53 PM, Jon Haddad wrote:I agree that new features should leverage SQL syntax.  I can't think of a reason not to. On Fri, Oct 31, 2025 at 5:00 PM Patrick McFadin wrote:I

Re: [DISCUSS] SQL support in Cassandra

I agree that new features should leverage SQL syntax. I can't think of a reason not to. On Fri, Oct 31, 2025 at 5:00 PM Patrick McFadin wrote: > I knew this would be a lot of information to try to convey. I swear it > sounded amazing in my head :D > > Let’s break up the Phase 1 and everything a

Re: [DISCUSS] SQL support in Cassandra

I knew this would be a lot of information to try to convey. I swear it sounded amazing in my head :D Let’s break up the Phase 1 and everything after it conversations. The Phase 1 part was in response to some recent discussions on current CEPs. CEP-55(https://lists.apache.org/thread/4swcf1n4qm7

Re: [DISCUSS] SQL support in Cassandra

Is the best path there really trying to transform CQL into SQL? Or is it building a native SQL implementation stateless on top of a backing ordered (ByteOrderedPartitioner), transactional (accord), key-value cassandra cluster ? It’s an extra hop, but trying to adjust the existing grammar / DDL t

Re: [DISCUSS] SQL support in Cassandra

Hey Patrick, Thanks for starting this discussion. I am also curious to read the response to Dinesh’s questions. Plus I have one to add myself (potentially more after I spend more time on this) - It is not clear to me what Phase 1 is. Do you suggest blocking 6.0 alpha to review all new not yet rel

Re: [DISCUSS] SQL support in Cassandra

Thank you Patrick for starting this thread. Your talk was interesting. I want to better understand the nature of compatibility aspect of what you're proposing. Specifically, how do you envision the following scenarios to be supported in this new world – 1. Could an operator enable CQL and SQL simu

[DISCUSS] SQL support in Cassandra

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