TypeQL vs SQL
@mark let's make a thread here since the channel you chose is for language design and engineering
9 Replies
here
ah ok, yes
I was wondering if there are more things to point out to a business or minimal techy user, to make them understand
that I may have overseen
pro:
- more complex queries with less effort
- easier to model and understand / maintain
- in AI friendly semantic form
_ some SQL queries wouldn't be possible to be executed
Cons:
- maybe speed
- are there limits in the sense of amount of data that can be processed?
Thomas once said, that some queries couldn't be executed in SQL
IMO the big ones are:
- Bring your data model to you, rather than you mental model to tables (no normalization etc). Excellent for domain driven design
- Natively model inheritance in data
- Extensible: you can basically operate like in Rust/C++ where you have a base model, and then extend existing types with new capabilities later! Hard to do in SQL IMO. We have users adding Role-based access to their data model post-hoc, which is cool
All of this is basically letting you manage data at a higher level of abstraction and tackle way more intrinsic complexity of your problem. Also like you said, easier to maintain and migrate.
i'm not entirely sure that there are queries SQL can't emulate, but for example recursion is a simple function for us and a complex recursive CTE in SQL, or you have build your own inheritance systems (all ways of doing that are painful)
Cons:
- not as fast or battle tested at scale (we just did our benchmark https://typedb.com/blog/first-look-at-typedb-3-benchmarks and also beyond that extended it to 1TB and things are still very snappy!
- not as much ecosystem around it
great, thank you!
need to think about a bit
really what we're converging on is saying that TypeDB is amazing for efficiently organizing data into structure @mark - higher level than just managing data in some tabular or graph format IMO
Yes, it’s more technical reasoning I’d say, thinking about advantages that come out of this for the business I need to figure out. Like less time (effort) to build, easier testing, better for AI LLM to reason about because of semantics etc
@joshua
I‘m sure Thomas mentioned that some queries would just die during execution because too complex or long
for sure - business values are i think
1) safety and correctness of data is enforced to a much higher standard due to having to specify the schema
2) evolution and mutation is part of the process, not so much an exceptional thing (we barely talk about this anyhow)
3) you can push down much more application code (eg enforcing data constraints, writing logic into reusable functions in the database, writing more complex queries since more is abstracted away), making your applications slimmer
4) our users spend much less time on database design than i think with other databases, once have their schema. Kinda like using Rust versus C
Yeah well i haven't tested this claim but you can definitely end up writing massive joins in SQL that could die at some point of complexity, or their query planner gets confused - and you can abstract that into niece pieces in TypeQL to end up with simpler queries to deal with for sure
but i dont know if it's provably true
Ok good, will have a call with my boss tomorrow and show him my usecase, so this helps me explaining it to him
And for AI it is beneficial to have a domain driven design, I think
yes - and TypeQL is also close to natural language, which helps a lot