Start a blog about deps.cloud HOT 4 CLOSED

• What are the advantages of supporting different databases and not being opinionated about this layer?

One benefit is the flexibility to switch technologies to account for different scales of data. If we find we hit a point where the current tech can't handle the requests we're making, we can replace it with another. The nice thing about our current offerings (sqlite, mysql, and postgres) is that it allows for a range of deployments (dev, read-only replicas, and an HA option).

With the current offerings, we are also able to meet a lot of companies where they are instead of requiring them to take on a new stateful system. Most clouds have support for Postgres. More traditional ecosystems use MySQL.

• In other words, why would a company/client prefer to pass in their own SQL statements?

To me, this is actually a different question. The pluggable SQL statements were more for the project, than for companies. Early on, there was an idea to eventually turn this into a SaaS solution. In that event, I wanted the core of the system to largely be the same but I places where I would extend the existing schema.

from deps.cloud.

A blog would be very useful. I had a question on the approach of supporting different databases or/and making this layer pluggable.

1. What are the advantages of supporting different databases and not being opinionated about this layer?
2. In other words, why would a company/client prefer to pass in their own SQL statements?

I'm sure there is a significant reason/advantage (just that I don't see it) with this and I think, writing on this would be of good value when people want to evaluate trade-offs of using deps-cloud vs a different system, for example.

from deps.cloud.

I did cover some of this in the docs, but not heavily.

https://deps.cloud/docs/architecture/#_how-should-the-data-be-stored_

from deps.cloud.

Very cool explanation, thank you!

from deps.cloud.