Hacker News new | past | comments | ask | show | jobs | submit login

It is probably one of the more common together with loading too much JavaScript and image content.

However even with that said a modern SQL database can handle A LOT of traffic and I've had discussions about internal CRUD applications with a couple of thousand users at most where people say we must use a document database because relational databases does not scale. Insane.

Of course people can use document databases and similar where it fits but you get a lot of nice things with a traditional rdmbs that you might miss later.

I haven't had a discussion about performance in years, weirdly enough, but people did default to the scalable solutions - even before knowing whether they needed it. Think new applications built using microservices. They also spent nearly two years before releasing something with a fraction of the features of the system it was supposed to replace.

If someone mentions a need for a technology choice based on performance, they had better come up with real numbers. Until they do, clarity, correctness and consistency should be the primary metrics. Don't solve a performance problem before you have the luxury of having a performance problem.

Premature scaling is akin to premature optimization.

On one of my recent projects, the highest use data was stored in DynamoDB. The entire dataset could trivially fit in RAM. So much wasted effort.

The org also over used Spark, event streams, and elasticsearch.

One could argue (rationalize) that using DynamoDB, for instance, for the small stuff builds team competency applicable to the big stuff. Or that using one set of tools reduces dependencies. I'd have to see some case studies. Because from where I was sitting, 90% of our maintenance costs were from mitigating bad sacred cow design decisions.

I've worked on similar metastatic tech debt based on NoSQL. Much as I love Redis, it's not a duck (fly, swim, walk).

I can understand the competency stuff. I was really blown away with React when that arrived and used it early, probably too early. React itself has been remarkably stable and consistent but everything around was chaotic for a couple of years. Anyway, we went all in in the department and builds all our front ends with React. I would argue it is a great fit for around half our applications as they are more complex but the rest could easily have been built with very little javascript enhancement. However now people can move between projects more easily and building something with React when you are comfortable with it and has a nice base is not slower than something else.

So I understand that people want to try new things but damn I wonder if I sounded the same when I wanted to start using React.

- "We can just use couchdb because then we won't have any problems with scale and we will never have to have any downtime because schema updates".

....yeah but that comes at a cost. You need to handle those schema updates in code. You need to handle those conflicts that arise from eventual consistency in code.

Anyway, I like the idea where you have a limited innovation budget where you can go for a new type of db but then you select other technologies that you are comfortable with and are true and tested. Not "Yeah, we will build this in a completely new way and we have no experience with docker, kubernetes, nodejs, document databases, vue.js, Elastic stack, prometheus or kibana" but this modern way of building things means everything will go much faster. Sometimes you have to go that route but the learning time can be pretty rough.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact