@garrison : After reading more of the thread, I agree that a native Elixir/Erlang/BEAM RDBMS could be a boon to the community (and open source in general), which would bolster the “Persistable Data” point in (Sasa Juric’s Server A vs Server B.
It could be a interesting value proposition (capability) to be able to:
- Deploy a new app that is all Elixir/Erlang/BEAM without the need for any external dependency (ala postgres).
- Then be able to just spin up new nodes (cluster) as data/traffic grows – app and data still colocated
- And if things get really serious, then there is some sort of “Cell Division” process to separate into different clusters (e.g. separate database from web-serving) – whatever data/domain topology makes sense for the project – and do it smoothly.
Yes, I think we all agree that BEAM ecosystem has qualities that no-others have to even be able to support the above.
Side Note: Just mentioning Bryan Hunter + Waterpark as the project recently popped up again in my feeds, and it seems at least tangentially related to this thread.
If DB is relational and I can use Ecto in the app, then I’m not as concerned about the flavor of human-usable query language (or dialect) is used to introspect the DB.
I would still want some sort of story about how devs/ops/dba can safely access the DB like I might do using pgAdmin (read-only) for ad-hoc queries to help debug/solve problems that may arise, or query the data for exploratory reporting-like queries. Whatever that may be. Ecto + LiveView? iex remote connection? Custom language?
So is the idea to take FoundationDB DNA-- ala, logical-key-ordering, key-range partitioned and replicated (LSM Tree powered?) with dynamic range splitting and migrations–, clean/tidy design details for BEAM, and use it as the “direct storage engine” lowest level lego blocks, then to build relational on top of that?
So is the imagination that there would be two deliverables: (1) a distributed and embeddable BEAM-native K/V (not OpenRiak), that has modern improvements to better support the (2) RDBMS for our community?
And that to get adoption, in addition to Ecto integration, Oban support would be required by the large populace of phoenix projects.
The intangibles goals/constraints being:
- Improving the Elixir/Erlang/BEAM ecosystem.
- The go-to data storage for new-apps in our community, not necessarily trying to usurp postgres yet.
- Added benefit for freedom and protection against the DB company “rug pull” inevitability?
- Open the door for new tech to be built on top of this-- Maybe a BEAM Large Object Storage?
Could an initial approach be to (top-down) implement an RDBMS feasibility toy-prototype using FoundationDB as the underlying abstraction to validate the idea, then work to rebuild the abstraction (bottom up) replace FDB?
I say this is all “Cool Beans”, and I hope the seed gets planted.
