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

11–20 of 233 posts

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

#11

Post by echelon »

nosefrog wrote: post #9

Coming from Google, where Spanner is this magical technology that supports infinite horizontal sharding with transactions and has become the standard storage engine for everything at Google (almost every project not using Spanner was moving to Spanner), I'm curious how Figma evaluated Cloud Spanner. Cloud Spanner does have a postgres translation layer, though I don't know how well it works. It seems like they've (hop…

Why would anyone marry themselves to Google? That sounds like the most boneheaded move possible.

First, you should never be beholden to a single vendor for the most critical technological underpinnings. You're backing yourself into a corner.

But more importantly, Google can't even figure out how to prioritize their cloud efforts. That's not a good partnership to be in for anyone except Google.

I wouldn't care if my solution was 10x worse than Cloud Spanner from a technology perspective. It'd be 1000x better from a strategy perspective.

You can hire engineers to do consistency at scale. It's your core competency and you can't just handwave and outsource that, lest you wind up stuck in a crevasse. Hire smart engineers and do the work yourself. It'll pay off.

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

#12

Post by [deleted] »

noja wrote: post #8
esafak wrote: post #7

Earlier quoted context omitted.

I agree with your general point but there are relational distributed databases, open source and "serverless", that are compatible with MySQL (planetscale, tidb, vitess...) and postgres (citus, cockroachdb...) edited for examples.

One reason they don't is unhelpful comments like these: alluding to products without naming them.

[deleted]

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

#13

Post by mamcx »

esafak wrote: post #2

This is such a familiar story. Company starts with a centralized database, runs into scaling problems, then spends man-years sharding it. Just use a distributed database.

There are many kinds of apps that use of "distributed" databases is an antipattern...and useless to make them scale.

MOST apps did not need more than "tenant-per-company" and then, maybe, distributed among a small set of servers.

Is it just that the kind of app that shows here (and has this problems) are just niche apps like social networks and complex chat apps.

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

#15

Post by hipadev23 »

nosefrog wrote: post #9

Coming from Google, where Spanner is this magical technology that supports infinite horizontal sharding with transactions and has become the standard storage engine for everything at Google (almost every project not using Spanner was moving to Spanner), I'm curious how Figma evaluated Cloud Spanner. Cloud Spanner does have a postgres translation layer, though I don't know how well it works. It seems like they've (hop…

The problem is nobody outside Google trusts them to run or operate anything.

Edit: To the Googlers downvoting these comments. Your behavior only reinforces our views.

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

#16

Post by ofrzeta »

noja wrote: post #8
esafak wrote: post #7

Earlier quoted context omitted.

I agree with your general point but there are relational distributed databases, open source and "serverless", that are compatible with MySQL (planetscale, tidb, vitess...) and postgres (citus, cockroachdb...) edited for examples.

One reason they don't is unhelpful comments like these: alluding to products without naming them.

From the article: "During our evaluation, we explored CockroachDB, TiDB, Spanner, and Vitess". Three of them are open source if I am not mistaken.

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

#17

Post by dang »

esafak wrote: post #2

This is such a familiar story. Company starts with a centralized database, runs into scaling problems, then spends man-years sharding it. Just use a distributed database.

"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

https://news.ycombinator.com/newsguidelines.html

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

#18

Post by battwell »

esafak wrote: post #2

This is such a familiar story. Company starts with a centralized database, runs into scaling problems, then spends man-years sharding it. Just use a distributed database.

Doesn't seem a crazy way to start a company. RDS will have scaling problems but is very mature and fairly easy to use early on when you're working on your MVP

I've used CRDB early on at a startup. There was some overhead. You don't get all the nice PSQL features

Although it did save us a giant migration later on

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

#20

Post by szundi »

hipadev23 wrote: post #15
nosefrog wrote: post #9

Coming from Google, where Spanner is this magical technology that supports infinite horizontal sharding with transactions and has become the standard storage engine for everything at Google (almost every project not using Spanner was moving to Spanner), I'm curious how Figma evaluated Cloud Spanner. Cloud Spanner does have a postgres translation layer, though I don't know how well it works. It seems like they've (hop…

The problem is nobody outside Google trusts them to run or operate anything. Edit: To the Googlers downvoting these comments. Your behavior only reinforces our views.

Google means: good chance discontinued after you have worked out the bugs and have a stable system at last
Post reply on HN