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

How Figma's databases team lived to tell the scale

figma.com

Post reply on HN
Print view View original

141–150 of 233 posts

Re: How Figma's databases team lived to tell the scale

#141

Post by petervandijck »

bjornsing wrote: post #29

One thought that comes up: Wouldn’t it be easier to have each customer in their own (logical) database? I mean, you don’t need transactions across different customers, right? So you’re essentially solving a harder problem than the one you’ve got. Not sure postgres (logical) databases would scale that well, but don’t see a principal reason why it couldn’t. Has anyone explored this further?

Ongoing product development with migrations, tweaking indexes etc. becomes really hard. Every small database tweak now has to be deployed over 1000s of databases.

Re: How Figma's databases team lived to tell the scale

#142

Post by yard2010 »

Scubabear68 wrote: post #55
bearjaws wrote: post #45

Earlier quoted context omitted.

I doubt even VC money can afford this service. Serverless Aurora is incredibly expensive for most workloads. I have yet to find a use case for any SaaS product that is used >4 hours a day. Since all my products span at least 3 time zones there is at least 12 hours of activity a day.

We found this out the hard way in a small startup. The per query and I/O expense was through the roof.

Did it work though? Did you achieve unlimited scaling? Because if so you should compare the price to the price of a team of great minds such as in this article, working for 2 years to get a solution.

I bet it still would be cheaper to pay people over Amazon, but I'm curious about the numbers

Re: How Figma's databases team lived to tell the scale

#143

Post by zarzavat »

paxys wrote: post #116
bjornsing wrote: post #29

One thought that comes up: Wouldn’t it be easier to have each customer in their own (logical) database? I mean, you don’t need transactions across different customers, right? So you’re essentially solving a harder problem than the one you’ve got. Not sure postgres (logical) databases would scale that well, but don’t see a principal reason why it couldn’t. Has anyone explored this further?

This works great until (1) your largest customer outgrows the largest available DB (happens sooner than you'd think for large companies) or (2) you do need transactions across different customers, say to facilitate some kind of sharing. Going all-in on the isolated tenant strategy means when you hit one of these cases it's a nightmare to unwind and rearchitect your entire DB layer.

Figma is more or less a desktop application that happens to run in a web browser.

If I use Photoshop to edit a .psd file I don’t think “man that psd file should really be stored in a single planet-sized database of all psd files in existence”. It’s just a file on my computer.

Figma requires a little bit more intermingling of data than Photoshop, it has multiuser support for one, so a pure local storage based approach wouldn’t work. But, at its heart it’s still based on the document model. When you open a Figma document it’s its own isolated little universe, the connections with resources outside the document are limited, and that matches user expectations.

Re: How Figma's databases team lived to tell the scale

#144

Post by thomasjudge »

salynchnew wrote: post #100
victor106 wrote: post #72

Earlier quoted context omitted.

> yet another one of Microsoft’s typical product naming crapshoots. Well said. I haven't seen any company as terrible as Microsoft at naming things. Anyone know why?

Naming things is hard. At a previous employer, I saw several cool-ish open source projects instantly doomed to obscurity by picking a name that either completely duplicated the name of an existing OSS project or were guaranteed to have terrible SEO for another reason. However, Microsoft seems to have a unique crossover of fragmented business units and centralized marketing. That's why you end up with Azure -> Subproj…

related, Microsoft on Microsoft marketing:

https://www.youtube.com/watch?v=EUXnJraKM3k

Re: How Figma's databases team lived to tell the scale

#145

Post by freefaler »

icedchai wrote: post #134
bjornsing wrote: post #29

One thought that comes up: Wouldn’t it be easier to have each customer in their own (logical) database? I mean, you don’t need transactions across different customers, right? So you’re essentially solving a harder problem than the one you’ve got. Not sure postgres (logical) databases would scale that well, but don’t see a principal reason why it couldn’t. Has anyone explored this further?

I worked at a place that did this with MySQL. Every tiny, trial account got their own database. Every huge, actual customer got their own database. Migrations were kinda painful. I would think carefully about doing it this way.

we've been doing this for 20k databases with mysql for the last 10+ years. It solves more problems than it creates. Migrations are trickier, but you get sharding, data isolation and easier backups that way.

Re: How Figma's databases team lived to tell the scale

#146

Post by thekhatribharat »

1. They mention that the largest tables ran into several TBs, and they would have soon topped the max IOPS supported by RDS. RDS for PostgreSQL peaks at 256,000 IOPS for a 64 TB volume. For a multi-AZ setup, this costs ~$70K/mo.

2. Let's assume the final outcome was a 5-way shard with each shard supporting ~50,000 IOPS and ~12 TB data. For a multi-AZ setup, this costs ~$100K/mo.

3. It took 9 months to shard their first table. Since it required application changes as well, let's assume this was 9mo * 20 work days/mo * (3 DB engineers + 2 app engineers) = 900 work days. Even at $100K avg. annual pay for an engineer, this is ~$400K.

4. A PostgreSQL-compatible NewSQL like YugabyteDB should cost ~$15K/mo to match top-of-the-line RDS performance. So Figma spent ~25x ($400K/$15K) to implement horizontal sharding in-house, and is still on RDS which costs ~6x ($100K/$15K)

Re: How Figma's databases team lived to tell the scale

#147

Post by r-bar »

victor106 wrote: post #72
junto wrote: post #41

Earlier quoted context omitted.

Before clicking on the article I assumed it was Citus, and was surprised when it wasn’t. Maybe because CitusData was bought by Microsoft around the same time, so Microsoft could create “Azure Cosmos DB for Postgres Cluster”, yet another one of Microsoft’s typical product naming crapshoots.

> yet another one of Microsoft’s typical product naming crapshoots. Well said. I haven't seen any company as terrible as Microsoft at naming things. Anyone know why?

The committee wanted Cosmos, Azure, and Postgres all in the name and wouldn't compromise.

Re: How Figma's databases team lived to tell the scale

#148

Post by chikitabanana »

thekhatribharat wrote: post #146

1. They mention that the largest tables ran into several TBs, and they would have soon topped the max IOPS supported by RDS. RDS for PostgreSQL peaks at 256,000 IOPS for a 64 TB volume. For a multi-AZ setup, this costs ~$70K/mo. 2. Let's assume the final outcome was a 5-way shard with each shard supporting ~50,000 IOPS and ~12 TB data. For a multi-AZ setup, this costs ~$100K/mo. 3. It took 9 months to shard their fir…

bhai, use the western numbering system, for clarity's sake. Thanks for the summary

Re: How Figma's databases team lived to tell the scale

#149

Post by tempnow987 »

callalex wrote: post #66
rockostrich wrote: post #54

Earlier quoted context omitted.

GCP products have a much better track record than Google consumer products when it comes to support since there are usually enterprise customers with multi-year contracts worth tens, if not hundreds, of millions of dollars using them.

That’s what AppEngine customers thought.

Didn't they also hammer folks using google maps in a business / cloud context?

I was also an old app engine user, but bailed ages ago (original app engine).

Re: How Figma's databases team lived to tell the scale

#150

Post by icedchai »

freefaler wrote: post #145
icedchai wrote: post #134

Earlier quoted context omitted.

I worked at a place that did this with MySQL. Every tiny, trial account got their own database. Every huge, actual customer got their own database. Migrations were kinda painful. I would think carefully about doing it this way.

we've been doing this for 20k databases with mysql for the last 10+ years. It solves more problems than it creates. Migrations are trickier, but you get sharding, data isolation and easier backups that way.

I'm not saying it's always a bad idea, you just need to think about what you're doing. This was closer to 15 years ago now. We had to develop a bunch of our own tooling, and make our own modifications to frameworks that are now ancient history.
Post reply on HN