4 ms·

I'd say YAGNI applies here since 95% of systems will never need to scale beyond the capabilities of a properly-configured RDBMS. Ensuring consistency and durabi

by dhd415 10y ago

I'd say YAGNI applies here since 95% of systems will never need to scale beyond the capabilities of a properly-configured RDBMS. Ensuring consistency and durability with a non-relational, distributed datastore generally requires a lot more detailed understanding of its internals than with a RDBMS, so choosing one of those rather than a RDBMS is going to impose costs that should be deferred until they're absolutely necessary.

oblio 10y ago
Plus it's waaay more likely that bugs in application code will haunt you even more. Especially the lack of things such as foreign keys and other constraints. Schemas can be straight jackets, but in many situations they're actually closer to life jackets.
- gerbilly 10y ago
  Totally agree that schemas are lifejackets. Carfully modelled data can outlive the application it was originally written for. Poorly structured data, on the other hand, where the schema and consistency is enforced in code is much harder to migrate. Maybe our problem is that we write systems with a disposable point of view? We don't even think the system will be around long enough to require migration.
luhn 10y ago
I think people underestimate just how far a properly-configured RDMS can scale. A machine with a couple CPUs and a few hundred gigs of memory can do a lot. Couple that with some tastefully-applied caching and query from a read replica when you can tolerate stale data... You can scale pretty far.
- brianwawok 10y ago
  And don't forget sharding. If your load is very much user focused.. i.e. user A only cares about the items for user A within the DB... you shard by user_id, and can now host 10 billion users on a farm of RDBMS. On the other hand, it gets more and more operationally complex as you add shards and failovers and such. If you KNOW you are going to hit that scale (say you are an established company with 100 million customers), it may not be the right choice.
  - luhn 10y ago
    Right. I'll remember that next time I'm an infrastructure lead at a company with a 100 million customers ;) But thanks for pointing out sharding. It can be powerful strategy.
    - user5994461 10y ago
      Once you are at a 100 millions customers company, the urgency becomes to ban all these MySQL and postgre for production systems. Or you need to figure out how to seriously handle a multi master setup in production. There are the 80% bottom of companies who are just toying around doing small products and MVP, that should stick to what's easy. There are the 5% at the top who are guaranteed to get 1 million customers no matter what they ship, that should stick to doing things right and sustainable from the start. Contrary to what the other comment state: sharding and failover are ALWAYS the EASIER choice at scale. The alternative is to be unable to change hardware/systems and to be forced into 15 hours downtime window for every maintenance/upgrade operation, which is a huge liability when you have real users. The 2 types of companies have opposite priorities.

by dhd415 10y ago

oblio 10y ago

Plus it's waaay more likely that bugs in application code will haunt you even more. Especially the lack of things such as foreign keys and other constraints. Schemas can be straight jackets, but in many situations they're actually closer to life jackets.

gerbilly 10y ago
Totally agree that schemas are lifejackets. Carfully modelled data can outlive the application it was originally written for. Poorly structured data, on the other hand, where the schema and consistency is enforced in code is much harder to migrate. Maybe our problem is that we write systems with a disposable point of view? We don't even think the system will be around long enough to require migration.

luhn 10y ago

I think people underestimate just how far a properly-configured RDMS can scale. A machine with a couple CPUs and a few hundred gigs of memory can do a lot. Couple that with some tastefully-applied caching and query from a read replica when you can tolerate stale data... You can scale pretty far.

brianwawok 10y ago
And don't forget sharding. If your load is very much user focused.. i.e. user A only cares about the items for user A within the DB... you shard by user_id, and can now host 10 billion users on a farm of RDBMS. On the other hand, it gets more and more operationally complex as you add shards and failovers and such. If you KNOW you are going to hit that scale (say you are an established company with 100 million customers), it may not be the right choice.
- luhn 10y ago
  Right. I'll remember that next time I'm an infrastructure lead at a company with a 100 million customers ;) But thanks for pointing out sharding. It can be powerful strategy.
  - user5994461 10y ago
    Once you are at a 100 millions customers company, the urgency becomes to ban all these MySQL and postgre for production systems. Or you need to figure out how to seriously handle a multi master setup in production. There are the 80% bottom of companies who are just toying around doing small products and MVP, that should stick to what's easy. There are the 5% at the top who are guaranteed to get 1 million customers no matter what they ship, that should stick to doing things right and sustainable from the start. Contrary to what the other comment state: sharding and failover are ALWAYS the EASIER choice at scale. The alternative is to be unable to change hardware/systems and to be forced into 15 hours downtime window for every maintenance/upgrade operation, which is a huge liability when you have real users. The 2 types of companies have opposite priorities.