[Zababa]

That's interesting. Have you tested this with another DB? The design makes a lot of sense, but I feel like it's the kind of thing that's hard to get right unless you actually test it. At the company I currently work, they switched DB some time ago. They already used interfaces but even that was not enough to make the switch, due to some differences in how the DBs worked.

[rmbyrro]

If you can map the differences in your code and your interface does not leak any implementation detail, you won't have problems.

But if the current database has features that can't be mapped to the new one, the interface won't save you.

Example: DynamoDB has a "time-to-live" feature [1]. You add a specific property to any item with a timestamp and it will auto-delete this item at the timestamp determined.

Few databases will provide this out of the box. If you choose to use it and later need to migrate, you'll have to implement your own kind of "TTL monitor" to perform the same task. The interface can't possibly save you from this.

But this would be an issue whether you decide to use a central interface or not, anyway...

[1] https://docs.aws.amazon.com/amazondynamodb/latest/developerg...

[Zababa]

Thanks, that "time-to-live" feature is a great exemple of what I was talking about. At work if I remember correctly it was something about not being able to read a write just after making it, and having to wait one second. I guess that's the kind of things where you either need people to be very careful when developing the implementation, or have people that have already been burned by that to think about that.