How Figma's databases team lived to tell the scale
1–10 of 233 posts
Re: How Figma's databases team lived to tell the scale
#2This 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.
Re: How Figma's databases team lived to tell the scale
#3This 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.
[deleted]
Re: How Figma's databases team lived to tell the scale
#4This 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.
This assumes that using a distributed database from the start doesn't offer it's own penalties/drawbacks (particularly in 2016).
Particularly considering as per the figma note, they consider their data highly relational (i.e. presumably this means lots of joins in queries)
What database would you have chosen?
Re: How Figma's databases team lived to tell the scale
#5This 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.
If every startup used every scale-proof method available from the beginning they'd never have the time or resources to build the products to get the customers that would require them to use the scale-proof methods
Re: How Figma's databases team lived to tell the scale
#6This 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.
This assumes that using a distributed database from the start doesn't offer it's own penalties/drawbacks (particularly in 2016). Particularly considering as per the figma note, they consider their data highly relational (i.e. presumably this means lots of joins in queries) What database would you have chosen?
That's a fair response for then, but not today where you're spoiled for choice. Spanner was released as a service in 2017, which isn't far off.
Re: How Figma's databases team lived to tell the scale
#7This 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.
If every startup used every scale-proof method available from the beginning they'd never have the time or resources to build the products to get the customers that would require them to use the scale-proof methods
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.
Re: How Figma's databases team lived to tell the scale
#8Earlier quoted context omitted.
If every startup used every scale-proof method available from the beginning they'd never have the time or resources to build the products to get the customers that would require them to use the scale-proof methods
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.
Re: How Figma's databases team lived to tell the scale
#9Coming 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 (hopefully only temporarily) given up real transactional support with their horizontal postgres scheme?
Re: How Figma's databases team lived to tell the scale
#10Earlier quoted context omitted.
If every startup used every scale-proof method available from the beginning they'd never have the time or resources to build the products to get the customers that would require them to use the scale-proof methods
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.
And many of these are substantially more expensive than RDS, or have terrible INSERT performance, or require making the correct decisions really early about what to use as partition keys. There's no free lunch, sadly.