Am I the only one here thinking they should have just used MongoDB and be done with it? I know over simplified approach but majority of problem would be solved.
Would literally any of the problem be solved?
Why Has Figma Reinvented the Wheel with PostgreSQL?
71–80 of 98 posts
Re: Why Has Figma Reinvented the Wheel with PostgreSQL?
#72I still can't understand why they decided to use a single database for all their customers. If each customer needs access to its own data, why not a dedicated database for every customer?
Multi-tenant design is a huge win in terms of reducing developer toil and expense.
Many customers will have a tiny amount of data. For those customers a dedicated database is huge amount of overhead. There may not be any single customer who it makes sense to allocate dedicated "hardware" for.
Sure you have to deal with a one-time pain to shard your thingy, but you don't need to pay for tens-of-thousands of individual database servers, write interesting tools to keep their schemas in sync, wrangle their backups, etc.
Re: Why Has Figma Reinvented the Wheel with PostgreSQL?
#73Earlier quoted context omitted.
It's easier to manage 1 database instead of 1000s
It's more expensive to screw up one all-important database than one of a thousand. Same logic allies to compute boxes, see "pets vs cattle" from 15-20 years ago.
The difference between "pets" and "cattle" are that pets have state and need to be taken care of, you can't recreate them from scratch trivially. Cattle are stateless and can be created and destroyed easily.
The whole point of a database is to contain the state - as a pet - so the rest of your application can be stateless - as cattle.
To really get cattle database systems, you need a self-managing cluster architecture that puts things on autopilot like Neon where you've got >=2 copies of each row and can tolerate losing any single box without unavailability.
Re: Why Has Figma Reinvented the Wheel with PostgreSQL?
#74Earlier quoted context omitted.
The article suggests a different reason. What would be your approach if you wanted to stay on RDS? > So, now, let me speculate. The real reason why Figma reinvented the wheel by creating their own custom solution for sharding might be as straightforward as this — Figma wanted to stay on RDS, and since Amazon had decided not to support the CitusData extension in the past, the Figma team had no choice but to develop th…
Wanting to stay on RDS is a reason doesn't survive the sort of extra scrutiny that I said should be applied in situations where you're doing a lot of work towards an internal goal. It also says in the article that they thought it was too risky to migrate (but somehow building their own sharding solution is going to be less risky for some reason). I could of course be wrong but it really just feels to me like the reas…
Looks like you can’t think of a good reason to stay on RDS in this case, is that correct?
Re: Why Has Figma Reinvented the Wheel with PostgreSQL?
#75Earlier quoted context omitted.
The article suggests a different reason. What would be your approach if you wanted to stay on RDS? > So, now, let me speculate. The real reason why Figma reinvented the wheel by creating their own custom solution for sharding might be as straightforward as this — Figma wanted to stay on RDS, and since Amazon had decided not to support the CitusData extension in the past, the Figma team had no choice but to develop th…
Fair. But it doesn't really explain why they wanted to stay on RDS. This is their reasoning: > over the past few years, we’ve developed a lot of expertise on how to reliably and performantly run RDS Postgres in-house. While migrating, we would have had to rebuild our domain expertise from scratch. So they had in house expertise to run performantly on RDS but that same experience couldn't be translated to switching ov…
Perhaps there were legal, compliance, or contractual constraints that made moving out of RDS impossible within their acceptable business risk levels?
Re: Why Has Figma Reinvented the Wheel with PostgreSQL?
#76Earlier quoted context omitted.
Seriously, a naive database sharding algorithm could be implemented in a week or so by a competent dev. A company like figma (billions in revenue) putting a small team to implementing a database sharding solution for an un-implemented use case (RDS, not just postgres). AND open sourcing it creating a value for the community is a net-good for the industry.
And that would be the solution you'd absolutely abhor. Database sharding has a bunch of gotchas and things to think about because you must consider query access patterns along with your sharding (unless you want the devs to get owned or have very weird behavior.) Building something super simple can be ok for the base use case but if you are a multi-billion dollar company you can probably afford a few dbas to actually…
Complexity is a great reason to implement something like this in-house. It's probably better to understand (and fully control) the sharding and transaction mechanism than to trust a third party with such a core piece of infra.
As companies get larger they move further up the stack whether it's sharding techniques, databases, custom orchestration software, their own networking hardware, etc.
Re: Why Has Figma Reinvented the Wheel with PostgreSQL?
#77Earlier quoted context omitted.
We went through something similar at Notion a few years ago and also chose to stick with RDS Postgres and build sharding logic in our application’s database client. In both our case and Figma’s, sharding Postgres ASAP was of critical importance because of transaction ID wraparound threat or other capacity issues that promise hard days-long downtime. The kind of downtime that costs 10s of millions of dollars of brand…
Or you could just hire some set of people who know how to manage postgres? Seems easier than building an entirely new thing with its own set of bugs that are unknown unknown brand damage awaiting you.
It seems that this day the art of configuring a database has been long lost. I also completely don't understand the issue. Just buy two huge behemoth servers, put your postgres there in a replicated mode and move on. It'll sustain huge load. Surely those companies can afford to hire one sysadmin.
Re: Why Has Figma Reinvented the Wheel with PostgreSQL?
#78Earlier quoted context omitted.
That doesn't sound right. Do data dump from prod for initial sync and then setup replication from RDS to new cluster. Once synced do switch. Then you're off RDS and can shard on Citus.
a) they didn't want to move off RDS b) this is a pretty big hand wave over migrating your persistence store on a moving product and moving engineering teams The coordination alone usually takes months
Yes, it takes months. They also spent months building this custom solution that they now need to maintain.
Re: Why Has Figma Reinvented the Wheel with PostgreSQL?
#79Earlier quoted context omitted.
That doesn't sound right. Do data dump from prod for initial sync and then setup replication from RDS to new cluster. Once synced do switch. Then you're off RDS and can shard on Citus.
This doesn't work with the constraint of "staying on AWS" though.
Yes it does.
Re: Why Has Figma Reinvented the Wheel with PostgreSQL?
#80Earlier quoted context omitted.
Fair. But it doesn't really explain why they wanted to stay on RDS. This is their reasoning: > over the past few years, we’ve developed a lot of expertise on how to reliably and performantly run RDS Postgres in-house. While migrating, we would have had to rebuild our domain expertise from scratch. So they had in house expertise to run performantly on RDS but that same experience couldn't be translated to switching ov…
I was puzzled by this as well. RDS is a managed, cloud product. You don't run it. The whole point is that AWS runs it for you, no?
It’s Postgres, large dbs will need some level of config and maintenance.
> Common DBA tasks for Amazon RDS for PostgreSQL
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appen...