Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The startup's Postgres survival guide

hatchet.run

Post reply on HN
Print view View original

231–240 of 255 posts

Re: The startup's Postgres survival guide

#231

Post by OrangeDelonge »

9dev wrote: post #215
williamdclt wrote: post #213

Earlier quoted context omitted.

ten times 50euros? Sounds like a very reasonable deal to not have to think about these things or spend the time setting it up.

If expending 6k per year on your database alone sounds reasonable to you, we have very different perspectives on a good use of investor funds. We’re not talking about maintaining your own k8s cluster here mind you, but a basic Postgres setup. If you can’t handle that comfortably in an afternoon, you probably shouldn’t be entrusted with customer data.

I think we live in very different realities, 6k a year is nothing, its a weeks worth of pay for 1 SWE. A 6k a year savings opportunity is not on any funded startups radar.

And RDS is doing a lot more for you than what you can set up in an afternoon w.r.t observability and features that are just a click away. I actually implemented some of those features when I worked there :)

Re: The startup's Postgres survival guide

#232

Post by drdexebtjl »

skullone wrote: post #230
drdexebtjl wrote: post #81

Earlier quoted context omitted.

> hiring at least a couple of DBAs and get more flexibility Every place I’ve ever worked at that had DBAs had the complete opposite of more flexibility. You have to do things the DBA’s way, and if their way doesn’t work for your service, you need to fight for their time and priority. Meanwhile every place I worked at where every team completely owned their databases + did periodic data recovery drills had much more f…

Now you have lots of DBs all probably operating inefficiently with only periodic recovery testing. This is the stuff DBAs do every day, and you're "hasn't happened to us... yet". You'll be just another lesson someday

Are you saying DBAs would be doing _continuous_ recovery testing? That’s not even a thing that exists.

Managed databases don’t lose customer data. They would be sued and lose, and if word got out, they would lose their customers. They are optimized for the machines they run on. The proprietary tooling from AWS for managing HA clusters, doing blue-green upgrades and monitoring for slow queries is all miles ahead of the open source tooling available for self-managed databases.

There’s nothing left for the DBA to do.

Re: The startup's Postgres survival guide

#233

Post by 9dev »

OrangeDelonge wrote: post #231
9dev wrote: post #215

Earlier quoted context omitted.

If expending 6k per year on your database alone sounds reasonable to you, we have very different perspectives on a good use of investor funds. We’re not talking about maintaining your own k8s cluster here mind you, but a basic Postgres setup. If you can’t handle that comfortably in an afternoon, you probably shouldn’t be entrusted with customer data.

I think we live in very different realities, 6k a year is nothing, its a weeks worth of pay for 1 SWE. A 6k a year savings opportunity is not on any funded startups radar. And RDS is doing a lot more for you than what you can set up in an afternoon w.r.t observability and features that are just a click away. I actually implemented some of those features when I worked there :)

We just might—not everyone works in SV. The 6k are a single database out of a vastly bigger pool of expenses, so unless you’re funded with six to seven digits from the start, it’s not nothing. At least in Europe, shelling out 300 grand on an SWE for an early stage company is delusional.

Re: The startup's Postgres survival guide

#235

Post by parmindergarcha »

mrkaye97 wrote: post #227
parmindergarcha wrote: post #220

Earlier quoted context omitted.

Noted that you only use this sparingly but you could try :- * Materialised views (especially if the computation/joins are particularly nasty). * Left outer joins are a good alternative to 'joins using case' and more likely to use the index.

Indeed! Materialized views won't work here as PG doesn't support "always updated" / "auto-refreshing" materialized views natively (although you can get something similar with extensions like TimescaleDB). Left joins are the thing we're often trying to avoid though, especially when the join conditions are involved, as we've seen the planner just make poor decisions in the past at unpredictable times. That's exactly th…

If left joins are causing issues, maybe for a quick win try increasing the sample size on the column(s) involved e.g. ALTER TABLE tablename ALTER COLUMN columnname SET STATISTICS 1000 - (default I think is 100), remember to run 'ANALYZE'.

Re: The startup's Postgres survival guide

#236

Post by 9dev »

mjr00 wrote: post #222
9dev wrote: post #217

Earlier quoted context omitted.

Well yeah, you can apply that to most problems you encounter as a company - there are service providers for pretty much anything you can imagine. That doesn't mean it's smart to spend a huge chunk of your revenue on OpEx, however.

Sure, and you need to do the build vs buy math, but why not take the "If you can’t handle that comfortably in an afternoon, you probably shouldn’t be entrusted with customer data." logic further and say 1. Don't use a third-party auth provider, if you can't build out an OAuth provider in an afternoon you shouldn't be entrusted with login credentials 2. Don't use Github, if you can't build out an internal Gitlab insta…

That's a straw man, obviously: I didn't talk about building your own database, but setting up PostgreSQL and pgBackRest, two well-defined, and thoroughly documented applications. With coding agents available, you don't need to much arcane domain knowledge for the fringe details, so a lot of the old reasons for appliances as a service don't hold anymore.

Other than that, yes! Setting up a Keycloak instance as opposed to handing over login credentials to Octa should be a consideration. Keeping your source code in GitLab over tying your entire development workflow to Microsoft vibe coders with an awful track record is a sensible stance.

> Don't use a lawyer or outsourced HR, if you can't draft legally binding employment agreement in an afternoon you shouldn't be entrusted with hiring people

That's a little ridiculous; there's an overlap between someone setting up a database for a startup and someone programmatically using a database at a startup. The overlap between that person and someone with a legal background is infinitesimally smaller.

Re: The startup's Postgres survival guide

#237

Post by dwedge »

drdexebtjl wrote: post #232
skullone wrote: post #230

Earlier quoted context omitted.

Now you have lots of DBs all probably operating inefficiently with only periodic recovery testing. This is the stuff DBAs do every day, and you're "hasn't happened to us... yet". You'll be just another lesson someday

Are you saying DBAs would be doing _continuous_ recovery testing? That’s not even a thing that exists. Managed databases don’t lose customer data. They would be sued and lose, and if word got out, they would lose their customers. They are optimized for the machines they run on. The proprietary tooling from AWS for managing HA clusters, doing blue-green upgrades and monitoring for slow queries is all miles ahead of th…

> There’s nothing left for the DBA to do.

And yet here we still are

Re: The startup's Postgres survival guide

#238

Post by dwedge »

throwaway894345 wrote: post #226
ktaraszk wrote: post #197

Earlier quoted context omitted.

They won't let you. It's part of their business to keep you locked in.

More likely it’s just not worth going out of their way to support niche deployments like that. I’ve been using various clouds for years, I’ve done half a dozen cloud migrations, currently working at a multicloud org—the vendors aren’t doing much to lock us in. They very much enable us to move platforms by offering things like bulk data transfer tools, standard application runtimes like Kubernetes, workload identity f…

> Like I have no doubt that they’re all greedy bastards, but they aren’t doing much to lock people in.

A few years ago we were trying to do a live migration from on-prem into GCP (mostly to have GCP as a failover option but move everything there if on-prem went down). We configured an async GCP slave from the on-prem cluster and once running it was easy. Multi-TB migration straight into CloudSQL with seconds of downtime.

Before we signed this off, we also tested the reverse - getting back from CloudSQL into on-prem. Turns out you couldn't (at the time, I'm not sure about currently) use CloudSQL as master for an external slave, only a slave to an external master. You could migrate the data in with no downtime, to get it back out was a multi-TB transfer. The door only opens one way.

So no, I am talking about lock in.

Re: The startup's Postgres survival guide

#239

Post by ozim »

bob1029 wrote: post #185
ozim wrote: post #115

Earlier quoted context omitted.

Don't use an ORM . Highly debatable. When your highest cost is developers salaries. Don't reinvent a type system by having a single table where each row can mean many different things depending on a "type int" enum col. Easy to say, harder to not do when you have business requirements on table, customer pressure and budget already gone on discussing with DBA who maybe is right but you are burning money right here and…

The best way to cure a developer of their ORM dependency is to put them on a project with a complex OLAP / data warehouse component. OLTP workloads are reasonably well aligned with a lot of ORM patterns so it's more difficult to demonstrate the caveats here (but it's definitely still possible). The limitations of ORMs are much more apparent with OLAP workloads. ORMs simply cannot cope with provider specific requireme…

Real problem I encounter usually is that business people (and devs) don’t understand OLAP vs OLTP.

They think they can bolt on dashboards or make interface having basically OLAP in the same project and make it perfectly performant.

Here in this thread you have bunch of devs claiming ORM doesn’t work - it works perfectly fine for OLTP. Those devs who claim to be so great knowing SQL also don’t seem to understand that business people are throwing them under bus requiring OLAP stuff to be bolted on OLTP application.

To add on that business people expect OLAP views or dashboards to be „real time” — only after they have dashboard developed to look at it once a month or once a quarter.

What also pains me when I deal with devs is that they pick up synchronization jobs, well batch jobs are fine but then they are scolded by business that batch jobs are slow. Where we have all kinds of tech to make event driven updates to OLAP environments.

Re: The startup's Postgres survival guide

#240

Post by skullone »

drdexebtjl wrote: post #232
skullone wrote: post #230

Earlier quoted context omitted.

Now you have lots of DBs all probably operating inefficiently with only periodic recovery testing. This is the stuff DBAs do every day, and you're "hasn't happened to us... yet". You'll be just another lesson someday

Are you saying DBAs would be doing _continuous_ recovery testing? That’s not even a thing that exists. Managed databases don’t lose customer data. They would be sued and lose, and if word got out, they would lose their customers. They are optimized for the machines they run on. The proprietary tooling from AWS for managing HA clusters, doing blue-green upgrades and monitoring for slow queries is all miles ahead of th…

DBAs in orgs who resource their data teams indeed do constant validation of recovery. I know many DBAs who are in more demand than ever due to the rise of managed databases. If you don't need a DBA, you aren't at a scale or maturity just yet. That you're so dismissive of this role, I have to dismiss your entire opinion because you simply don't grasp the scale of large databases
Post reply on HN