Introduction

Ash seems to be great with regular relational data. However when I tried it out for a hobby project, where I had to represent a hierarchy of arbitrary depth, I noticed there isn’t any support for graphs or any other non relational data. I propose that data layers for some NoSQL DBs/Postgres Extension be created.

Now, I firmly believe that 90% of modern requirements can be met with a regular RDBMS. It take a very significant load and a number of optimizations elsewhere in the stack before your database becomes a bottleneck. However, there are cases where you genuinely need more than vanilla postgres or even a specialized DB. As such, my approach would be to have as little information outside of standard postgres as possible, while also limiting the number of extra services my app depends on.

Postgres and friends

One approach to enforce this principle is to stick to postgres extensions like Apache AGE (for graphs), TimescaleDB (for time-series) and JSONB (for documents). Since we are only extending the functionality of our primary database, there are 2 main of advantages:

• No consistency problems/data duplication between DBs (since there’s only one DB)
• Simplified deployment and reduced footprint (since there’s only one service)

However, this raises the important question: do MySQL and SQLite become second class citizens compared to Postgres in Ash? It’s possible that MySQL has equivalents for all these extensions, and we can support these features on top of AshPostgres and AshMySQL.

NoSQL DBs

The disadvantage with Postgres Extensions is that they may or may not be as performant as specialized solutions. Additionally they tend to have a smaller user base than specialized solutions. Supporting NoSQL DBs though, is a difficult task:

• How do we decide how much data to duplicate between DBs?
• How do we ensure consistency?
• When does an implementation become too opinionated and actively hinder the user when he steps off the beaten path?
• Are Postgres, MySQL and SQLite even replaceable (as they are now) when used with conjunction with a NoSQL DB?

I personally think that integrating additional databases is a problem best solved on a case-by-case basis. I don’t even think Ash trying to solve for the scale and the unique cases that demand a NoSQL database is even right thing to do, since the vast majority of Ash’s users don’t and will not operate at that scale.

Further Steps

The main question to answer is if we want to go with supporting the database extensions, or the NoSQL DBs or both and we fill in the details after that.

If we were to go with just Postgres, the order I would implement these would be:

0. jsonb (already supported) → Document DB
1. timescaledb (since it’s essentially a regular table, but optimized for time) → Time-Series DB
2. pgvector (since it’s just an extra datatype with a few vector specific extensions to SQL) → Vector DB
3. age (since graphs are queried with Cypher and not SQL) → Graph DB
4. postgis (since a lot of specialized GIS expertise is required) → Geospatial DB

I’m happy to help if this a direction Ash Core wants to go.

If there’s demand, we could support hstore as a Redis replacement, but I’m not sure for what’s the point in the context of Elixir (or even if you need it anyway when you’ve got jsonb).