Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for alternative SQL engine providers #95

Open
mjaric opened this issue Dec 14, 2017 · 6 comments
Open

Support for alternative SQL engine providers #95

mjaric opened this issue Dec 14, 2017 · 6 comments

Comments

@mjaric
Copy link

mjaric commented Dec 14, 2017

Hi Guys,

Would be possible to add a layer where we could swap store providers? So instead of Postgrex, one could configure Tds or Mariaex.... I'm willing to contribute but I will need your guidance since I haven't scanned code yet.

Thanks

@slashdotdash slashdotdash changed the title New Feature: Support for sql engine providers Support for alternative SQL engine providers Dec 14, 2017
@slashdotdash
Copy link
Member

slashdotdash commented Dec 14, 2017

@mjaric Making EventStore back-end agnostic has been mentioned a few times (e.g. #22).

The EventStore.Storage module would be the most suitable place to define a behaviour that could then be implemented by alternate storage providers. The existing modules in lib/event_store/storage are Postgres-specific and could be renamed appropriately (e.g. EventStore.Storage.Postgres).

@slashdotdash
Copy link
Member

slashdotdash commented Dec 14, 2017

I would be interested to hear which alternative SQL databases people would like to use.

Please feel free to add a comment, or +1, to this issue to show your interest.

@fire
Copy link

fire commented Jan 3, 2018

Cockroachdb should be the easiest one and it mimicks postgresql.

@fpauser
Copy link

fpauser commented Oct 26, 2018

SQLite would be great.

@ronlobo
Copy link

ronlobo commented Jan 29, 2020

YugaByteDB would be perfect.

@aschrijver
Copy link

Also fan of SQLite support. For a server app where that's used for lightweight uses and ability to swap to Postgres if the workload demands it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants