FDB is a functional database written in Rust.
Functional means that the query language of the database is based on functions. That is, filters, projections, aggregations, etc... are all passed to the query engine as functions.
The query language itself is heavily influenced by existing functional APIs for data processing, e.g. the List API in Haskell or the Stream API in Java.
Basic operations like filter and fold are composable to generate arbirtarily complex queries.
Don't we have enough databases out there already?
Yes we do.
Aren't they performant enough?
They are very performant.
Then what is the goal?
The goal of the FDB project is not to revolutionize the field of databases or "beat" any existing systems. It is a personal project with the following goals:
- Devise an expressive functional query language that is:
- more expressive than SQL
- easier to write than SQL
- "elegant" from a programming language designer's point of view (see section "Motivation")
- Implement a basic database core that supports said language as its main query language
- Get performance on par with existing SQL systems
Bear in mind this is also a personal project with the following personal goals:
- Learn Rust by implementing a large and complex system
- Have fun designing and implementing a database!
The goal of FDB is not to:
- Become the new PostgreSQL
- Become the new Oracle
- Be the fastest
But why?
With a modern language designer's eye, the following features of the SQL language make it a bad language:
The SQL language suffers from the following major design flaws at its core:
- Limited/cumbersome composability.
The
SELECT/FROM/WHEREsyntax of the language makes it cumbersome to compose small elements. For example, to add a filter on top of an existing query block, one needs to write an entireSELECT/FROM/WHEREstatement, even though theWHEREclause is the only one containing actual logic. This makes it hard for external tools to code generate to SQL (add external refs here). This structure is also hard to analyze directly, and is therefore torn down relatively early on in the SQL compilation process of most RDBMS systems, in favor of a simpler tree of operators closer to relational algebra and modern functional data processing APIs. - Context-based semantics. Aggregators with/without
- Generic reusability. argmax example
- Fully iniline writing of programs
- All declarative (hard to write) No variables thazt dan store subauery (WITH clausee now)
- no nesting
- special everything: types, operators, ...