SQL is costly sugar for OLTP
Why?
- OLTP has fixed access, so sql parsing/planning is a waste (parsing + planning can take up to few hundred microseconds per query)
- SQL usage trends also makes it hard to secure db (cause logic not on db), string parsing allowing injection, permission not on function level, etc
- This trend also make concurrency management harder (cause longer window)
- Also encourage user to create subpar design, not well thought, because so dynamic
What SQL got right
- Easily evolvable API, all just a single long string. This also makes it easy to implement lots of server side function, such as
coalesce
, now
, date-related function, etc, without the need to do read first over network
- Composability. Everything is just a table
DB favoring real programming language from SQL
- FDB Record Layer
- Fauna
- Palantir’s AtlasDB
some other resources
- Against SQL
- Some Opinionated SQL takes
- RonDB internals
- Linkedin’s Liquid
- FDB Record Layer