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

Why Has Figma Reinvented the Wheel with PostgreSQL?

medium.com

Post reply on HN
Print view View original

11–20 of 98 posts

Re: Why Has Figma Reinvented the Wheel with PostgreSQL?

#11

Post by winrid »

djtango wrote: post #9
winrid wrote: post #8

Earlier quoted context omitted.

Absolutely not. Citus would have solved this problem. Or move to MySQL and use PlanetScale etc. Second best option is ability to easily create prod environments, and then give those to your biggest customers (bigname.figma.com) etc. No single figma customer will go beyond an i3.metal for the DB, or the app.

So I just read the article - they were on RDS so Citus wasn't an option. They also stated it was too risky to migrate data stores on the timeline they were working within Those all seem like measured engineering decisions AFAICT

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.

Re: Why Has Figma Reinvented the Wheel with PostgreSQL?

#13

Post by raverbashing »

winrid wrote: post #11
djtango wrote: post #9

Earlier quoted context omitted.

So I just read the article - they were on RDS so Citus wasn't an option. They also stated it was too risky to migrate data stores on the timeline they were working within Those all seem like measured engineering decisions AFAICT

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.

Yes but they probably wouldn't want to migrate off RDS.

Re: Why Has Figma Reinvented the Wheel with PostgreSQL?

#14

Post by nathanappere »

winrid wrote: post #11
djtango wrote: post #9

Earlier quoted context omitted.

So I just read the article - they were on RDS so Citus wasn't an option. They also stated it was too risky to migrate data stores on the timeline they were working within Those all seem like measured engineering decisions AFAICT

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.

Re: Why Has Figma Reinvented the Wheel with PostgreSQL?

#15

Post by Ozzie_osman »

I'm at a company that is weighing a very similar decision (we are on RDS Postgres with a rapidly growing database that will require some horizontal partitioning). There really isn't an easy solution. We spoke to people who have done sharding in-house (Figma, Robinhood) as well as others who migrated to natively distributed systems like Cockroach (Doordash).

If you decide to move off of RDS but stay on Postgres, you can run your own Postgres but now lose all the benefits of a managed service. You could move off of AWS (eg to Azure), but moving to a different cloud is a huge lift. That, btw, would also be required if you want to try something like Spanner (move to GCP). Moving off of Postgres to another database is also risky. The migration will obviously take some effort, but you're also probably talking about lots of code changes, schema changes, etc, as well as unknown operational risks that you'll discover on the new system. This applies if you're talking about things like Cockroach or even moving to MySQL.

That said, rolling your own sharding is a MASSIVE undertaking. Limitless looks promising, since it takes care of a lot of the issues that Figma ended up spending time on (basically, you shouldn't need something like Figma's DBProxy, as shard routing, shard splitting, etc will be taken care of). It's still in preview though, and like the article mentioned, the costs may be high.

Overall, no easy decisions on this one, unfortunately.

Re: Why Has Figma Reinvented the Wheel with PostgreSQL?

#16

Post by thibaut_barrere »

seanhunter wrote: post #4

The answer is obvious: they invented their own sharding solution because it's a really really cool problem to work on and they have more engineers than they really need to develop their actual product. A more resource-constrained team would have found a solution that sharded their backend using one of the existing solutions out there. I have seen this several times before and it's always a symptom of having too many…

I don't read the story this way personally (not saying that these scenarios do not occur, but I feel the narrative detailed in the original article makes sense even without "chasing cool problems").

Re: Why Has Figma Reinvented the Wheel with PostgreSQL?

#17

Post by thibaut_barrere »

djtango wrote: post #9
winrid wrote: post #8

Earlier quoted context omitted.

Absolutely not. Citus would have solved this problem. Or move to MySQL and use PlanetScale etc. Second best option is ability to easily create prod environments, and then give those to your biggest customers (bigname.figma.com) etc. No single figma customer will go beyond an i3.metal for the DB, or the app.

So I just read the article - they were on RDS so Citus wasn't an option. They also stated it was too risky to migrate data stores on the timeline they were working within Those all seem like measured engineering decisions AFAICT

I do agree here. The choice to prefer X over Y for hosting (no matter X and Y) often makes sense, changing hosting providers can take a bit of time & it's hard to fully assess the reality of the quality of support / security (again, not specifically writing about RDS or Citus, both are very good teams) beforehand, so it usually is safer to have a long probing period to move safely, which takes time, something they visibly didn't have much.

Re: Why Has Figma Reinvented the Wheel with PostgreSQL?

#18

Post by thih9 »

seanhunter wrote: post #4

The answer is obvious: they invented their own sharding solution because it's a really really cool problem to work on and they have more engineers than they really need to develop their actual product. A more resource-constrained team would have found a solution that sharded their backend using one of the existing solutions out there. I have seen this several times before and it's always a symptom of having too many…

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 their own sharding solution from scratch.

Re: Why Has Figma Reinvented the Wheel with PostgreSQL?

#20

Post by djtango »

winrid wrote: post #11
djtango wrote: post #9

Earlier quoted context omitted.

So I just read the article - they were on RDS so Citus wasn't an option. They also stated it was too risky to migrate data stores on the timeline they were working within Those all seem like measured engineering decisions AFAICT

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

Post reply on HN