3 ms·

As long as you have good interfaces in your code to make it possible to swap out Postgres to more specialized components when needed, I think it’s a good idea.

As long as you have good interfaces in your code to make it possible to swap out Postgres to more specialized components when needed, I think it’s a good idea. Saving ops resources by managing fewer services when getting started is a good idea, until scale necessitates dedicated technologies for certain components.

glutamate 4y ago
I wouldn't even worry about coding to interfaces. When you need to replace Postgres because you have more than 1M users, you will probably have the revenue to refactor your code to swap out Postgres dependencies. Because you have good integration and E2E tests, right?
- thomaslangston 4y ago
  Good tests are a lot easier to write with good interfaces.
  - isbvhodnvemrwvn 4y ago
    Database abstraction layers are leaky, if you don't test things like isolation levels or other tricky behaviors, those tests will have limited value.
    - jimbokun 4y ago
      Limited value is better than no value.
- marcosdumay 4y ago
  At such time you will also have plenty of interesting new problems that require changing most of your code anyway. I agree that hedging against having to move from a FOSS database is pure waste.
cube2222 4y ago
That will make you lose a lot of productivity boosts SQL can give you. Obviously, if you anticipate to have very high traffic and applicable usage patterns, do use that advice, but if your apps anticipated usage pattern is in fact not "very high rps per buck made", then I recommend the opposite. I've went the whole way from very-well-abstracted-away services/repositories to an almost complete lack of abstraction. Direct SQL or ORM in your functions, operating on many models at once, with a real postgres database available to all your unit tests, treating the SQL code as part of your application logic. Transaction per test so that unit tests are fast to run. I've been very happy since. SQL is very powerful if you use it as SQL and not as a glorified KV store.
- lukeramsden 4y ago
  To me, good modularity at the data layer doesn't mean abstracting away Postgres or even SQL. To me, it means having a separation of concerns between loading data, writing data, and _processing data as domain objects_. Don't have your core business logic operate over database rows, but in-memory objects. You can test the loaders/writers separately to your actual logic at that point.
  - cube2222 4y ago
    > Don't have your core business logic operate over database rows This is the part where I don't agree, as SQL is very expressive, and needlessly loading data to your app is also not performant (making the transition to something else required sooner). I think writing parts of your business logic in SQL that make sense to be written in SQL is just fine. If you only use it to load and write entities, then that is basically a glorified KV store.
dathinab 4y ago
Often writing abstract interfaces costs more then switching things out by changing your code. So it's often better to keep concerns separated and make it so that code is easy to change, but creating abstract interfaces is often not worth it for a lot of products.
alch- 4y ago
YAGNI!

glutamate 4y ago

I wouldn't even worry about coding to interfaces. When you need to replace Postgres because you have more than 1M users, you will probably have the revenue to refactor your code to swap out Postgres dependencies. Because you have good integration and E2E tests, right?

thomaslangston 4y ago
Good tests are a lot easier to write with good interfaces.
- isbvhodnvemrwvn 4y ago
  Database abstraction layers are leaky, if you don't test things like isolation levels or other tricky behaviors, those tests will have limited value.
  - jimbokun 4y ago
    Limited value is better than no value.
marcosdumay 4y ago
At such time you will also have plenty of interesting new problems that require changing most of your code anyway. I agree that hedging against having to move from a FOSS database is pure waste.

cube2222 4y ago

That will make you lose a lot of productivity boosts SQL can give you. Obviously, if you anticipate to have very high traffic and applicable usage patterns, do use that advice, but if your apps anticipated usage pattern is in fact not "very high rps per buck made", then I recommend the opposite. I've went the whole way from very-well-abstracted-away services/repositories to an almost complete lack of abstraction. Direct SQL or ORM in your functions, operating on many models at once, with a real postgres database available to all your unit tests, treating the SQL code as part of your application logic. Transaction per test so that unit tests are fast to run. I've been very happy since. SQL is very powerful if you use it as SQL and not as a glorified KV store.

lukeramsden 4y ago
To me, good modularity at the data layer doesn't mean abstracting away Postgres or even SQL. To me, it means having a separation of concerns between loading data, writing data, and _processing data as domain objects_. Don't have your core business logic operate over database rows, but in-memory objects. You can test the loaders/writers separately to your actual logic at that point.
- cube2222 4y ago
  > Don't have your core business logic operate over database rows This is the part where I don't agree, as SQL is very expressive, and needlessly loading data to your app is also not performant (making the transition to something else required sooner). I think writing parts of your business logic in SQL that make sense to be written in SQL is just fine. If you only use it to load and write entities, then that is basically a glorified KV store.

dathinab 4y ago

Often writing abstract interfaces costs more then switching things out by changing your code. So it's often better to keep concerns separated and make it so that code is easy to change, but creating abstract interfaces is often not worth it for a lot of products.

alch- 4y ago

YAGNI!