undefined | Better HN

0 pointsdukeyukey1y ago0 comments

Both scale well beyond the point of most applications, but aren't overly complex to get running.

0 comments

6 comments · 1 top-level

sgarland1y ago· 5 in thread

MySQL is equally easy to get running, and has FAR less maintenance overhead. It also scales better on its own, due to a threaded connection model vs. Postgres’ process model. The main trade-off is less extensibility, but IME Postgres’ more esoteric types are rarely used anyway.

The other tradeoff (perhaps larger, actually) is poor performance if using a non-k-sortable PK, like a UUIDv4. Unfortunately this is extremely common.

KronisLV1y ago

Golang is great but depending on the job market in a given country, might be a little bit esoteric.

If you were aiming for one of the more popular options that still scale pretty well, you might pair either PosgreSQL/MariaDB/MySQL with one of the JVM languages (e.g. Java) or one of the CLR languages (e.g. C#). Both runtimes and their languages are okay and have pretty big ecosystems.

Then again, Node or even PHP might be enough for most apps, maybe even Python or Ruby with a bit of vertical (and simple horizontal) scaling down the line.

Just be prepared for that monolith to grow into an eldritch nightmare of dependencies somewhere between 5 to 15 years later. Currently working on such a Java system, it makes the laptop thermal throttle regularly.

ndriscoll1y ago

The process thing is irrelevant if you're using a decent database library with connection pooling. Mysql also performs/scales better when keeping connection count proportional to the hardware. I'm personally not a fan of golang (scala has similar performance while being much easier to maintain IMO), but at least pooling is normal/relatively transparent there.

As with using many connections, a UUIDv4 PK is a case of "don't do that".

sgarland1y ago

I’d say greatly reduced in magnitude, but not irrelevant. I’d also prefer to use middleware like PgBouncer or PgCat rather than relying on a library’s connection pooler, mostly because the latter IME has a habit of causing fun surprises from people not properly handling transactions.

> “don’t do that”

If I could get people to use RDBMS properly, I’d be both thrilled and potentially out of a job.

andrewstuart1y ago

>> MySQL is equally easy to get running, and has FAR less maintenance overhead

None of these ring true for me.

>> It also scales better on its own, due to a threaded connection model vs. Postgres’ process model.

My understanding is that Postgres has an excellent SMP design that gives almost linear vertical scale. Couldn't quickly find good backup docs.

>> FAR less maintenance overhead

What do you mean by "maintenance overhead"? I don't find Postgres needs much maintenance let along FAR less.

sgarland1y ago

> None of these ring true for me.

In what way?

> What do you mean by "maintenance overhead"? I don't find Postgres needs much maintenance let along FAR less.

At small scale, you likely won’t notice. Once your tables get up to 10s or 100s of millions of rows, you will.

Autovacuum will need tuning, both globally and per-table.

Indices will need periodic re-indexing.

Specific columns in tables may need custom statistics targets.

TXID wraparound, though this isn’t so much maintenance as it is a waking nightmare that you have to monitor for.

Don’t get me wrong, I quite like Postgres. However, IME from having ran large-ish (10s of TB) clusters of both, MySQL tends to Just Work.

j / k navigate · click thread line to collapse

0 comments

6 comments · 1 top-level

sgarland1y ago· 5 in thread

The other tradeoff (perhaps larger, actually) is poor performance if using a non-k-sortable PK, like a UUIDv4. Unfortunately this is extremely common.

KronisLV1y ago

Golang is great but depending on the job market in a given country, might be a little bit esoteric.

Then again, Node or even PHP might be enough for most apps, maybe even Python or Ruby with a bit of vertical (and simple horizontal) scaling down the line.

ndriscoll1y ago

As with using many connections, a UUIDv4 PK is a case of "don't do that".

sgarland1y ago

> “don’t do that”

If I could get people to use RDBMS properly, I’d be both thrilled and potentially out of a job.

andrewstuart1y ago

>> MySQL is equally easy to get running, and has FAR less maintenance overhead

None of these ring true for me.

>> It also scales better on its own, due to a threaded connection model vs. Postgres’ process model.

My understanding is that Postgres has an excellent SMP design that gives almost linear vertical scale. Couldn't quickly find good backup docs.

>> FAR less maintenance overhead

What do you mean by "maintenance overhead"? I don't find Postgres needs much maintenance let along FAR less.

sgarland1y ago

> None of these ring true for me.

In what way?

> What do you mean by "maintenance overhead"? I don't find Postgres needs much maintenance let along FAR less.

At small scale, you likely won’t notice. Once your tables get up to 10s or 100s of millions of rows, you will.

Autovacuum will need tuning, both globally and per-table.

Indices will need periodic re-indexing.

Specific columns in tables may need custom statistics targets.

TXID wraparound, though this isn’t so much maintenance as it is a waking nightmare that you have to monitor for.

Don’t get me wrong, I quite like Postgres. However, IME from having ran large-ish (10s of TB) clusters of both, MySQL tends to Just Work.

j / k navigate · click thread line to collapse