4 ms·

That’s reasonable advice for growth stage companies aiming for huge user bases. I work at an Alexa top10k, and our database server is quite small and sits at a

That’s reasonable advice for growth stage companies aiming for huge user bases. I work at an Alexa top10k, and our database server is quite small and sits at about 10% load most of the time. You can grow huge with vertical scaling. Not all the way to “household name” size, but still truly huge. Servers with tens of tb of ram are available by the hour.

fomine3 5y ago
Licensing cost is another factor. DBMS tend to be paid software than Web application server. Scaling up Oralce sometimes very expensive.
- munk-a 5y ago
  Oracle is extremely expensive. I've been using Postgres for a long time and you can eek quite a bit of performance out of it.
scosman 5y ago
Really really expensive servers that sit at 10% load most of the time is one of the points.
- danielheath 5y ago
  This isn’t an expensive server. It’s just not a problem that requires substantial resourcing.
rualca 5y ago
> That’s reasonable advice for growth stage companies aiming for huge user bases. Not really, that's the result of hard-earned lessons that pay off from day 1. Think about it: you have data in a database, and you put up an API to allow access to it. Your API needs change, and now you need to make available a resource with/without an extra attribute. You need to provide it as a new API version in parallel with the current API version you're supporting. What will you do then? Reupdate the whole db with a new migration? Put up two databases? Or are you going to tweak the DTO mapper and be done with it?
- BenjieGillam 5y ago
  Or use an API layer such as GraphQL that doesn’t require versioning for such a minor change since additive changes (or deprecations) to the API do not affect existing queries - each query states exactly what it needs.
  - rualca 5y ago
    > Or use an API layer such as GraphQL (...) But that already qualifies as the boilerplate code that was supposedly the root problem, isn't it? But now instead of a simple mapper you've bolted on another complex system. So exactly how does JSON in the db solve any of the problems that were presented? Other than adding two buzzwords, what were the improvements?
  - munk-a 5y ago
    Backwards incompatible changes will eventually be required by the business - at least once that business is oriented such that technical concerns do not overrule all other concerns.
- danielheath 5y ago
  I use a database that was designed by someone who understands one sometimes wants to run a migration. It’s not hard to add new fields. Perhaps my experience is unusual having worked on a distributed database for several years but this stuff just seems like table stakes.
  - rualca 5y ago
    > I use a database that was designed by someone who understands one sometimes wants to run a migration. It’s not hard to add new fields. We're not talking about adding attributes to a database. We're talking about one of the most basic cases in API design: changing a interface and serving two or more versions. If the mapping step between getting data from the db and outputting it in a response is expected to be eliminated by getting the DB to dump JSON, how is this issue solved? And how exactly is a full blown db migration preferable to mapping and serializing a DTO?

fomine3 5y ago

Licensing cost is another factor. DBMS tend to be paid software than Web application server. Scaling up Oralce sometimes very expensive.

munk-a 5y ago
Oracle is extremely expensive. I've been using Postgres for a long time and you can eek quite a bit of performance out of it.

scosman 5y ago

Really really expensive servers that sit at 10% load most of the time is one of the points.

danielheath 5y ago
This isn’t an expensive server. It’s just not a problem that requires substantial resourcing.

rualca 5y ago

> That’s reasonable advice for growth stage companies aiming for huge user bases. Not really, that's the result of hard-earned lessons that pay off from day 1. Think about it: you have data in a database, and you put up an API to allow access to it. Your API needs change, and now you need to make available a resource with/without an extra attribute. You need to provide it as a new API version in parallel with the current API version you're supporting. What will you do then? Reupdate the whole db with a new migration? Put up two databases? Or are you going to tweak the DTO mapper and be done with it?

BenjieGillam 5y ago
Or use an API layer such as GraphQL that doesn’t require versioning for such a minor change since additive changes (or deprecations) to the API do not affect existing queries - each query states exactly what it needs.
- rualca 5y ago
  > Or use an API layer such as GraphQL (...) But that already qualifies as the boilerplate code that was supposedly the root problem, isn't it? But now instead of a simple mapper you've bolted on another complex system. So exactly how does JSON in the db solve any of the problems that were presented? Other than adding two buzzwords, what were the improvements?
- munk-a 5y ago
  Backwards incompatible changes will eventually be required by the business - at least once that business is oriented such that technical concerns do not overrule all other concerns.
danielheath 5y ago
I use a database that was designed by someone who understands one sometimes wants to run a migration. It’s not hard to add new fields. Perhaps my experience is unusual having worked on a distributed database for several years but this stuff just seems like table stakes.
- rualca 5y ago
  > I use a database that was designed by someone who understands one sometimes wants to run a migration. It’s not hard to add new fields. We're not talking about adding attributes to a database. We're talking about one of the most basic cases in API design: changing a interface and serving two or more versions. If the mapping step between getting data from the db and outputting it in a response is expected to be eliminated by getting the DB to dump JSON, how is this issue solved? And how exactly is a full blown db migration preferable to mapping and serializing a DTO?