Hacker News Reader

Comment by leesalminen | Hacker News Reader

Totally agree. I used Google Cloud Functions + Google Cloud Storage to deploy a single function “app”. We replaced a SaaS that was a UI for recurring plan signups over Stripe. It started costing us $500/Mo. I replaced it with 16 hours dev+testing.

It turned out really well and am very happy with it thus far. I expect maintenance to be minimal thanks to serverless.

Though I don’t think it’d work as well for an app with 100+ database tables. Definitely a middle ground in there.

View on HN

Just curious, what kinds of apps use 100+ database tables? I don't know too much about this stuff.

We offer a SaaS product that helps manage pet services businesses. Think CRM+POS+ERP all mashed together, targeted at a niche. Our app is highly configurable by each business. It turns out these businesses are pretty complex :). We’re at 152 production tables today.

Our core banking app has 1000+ tables.

This sub-thread is fascinating. On the pet service business, it sounds like there might be more tables due to some kind of object polymorphism on a per customer basis? Are there any other "per-whatever" expansion factors that are multiplying your table count?

A CRM+POS+ERP is pretty complex by itself, and being more configurable means more stuff is in the database vs the code.

I work with a platform that also does CRM/POS/ERP (plus a bunch more), and the products alone have over 10 tables for describing them: the base products, their variants, a list of generic variant attributes, a table detailing which variants have which attributes, a table for specifying the values that those variants have of those attributes, the product categories, two tables for configuring the taxes applied to each product (on purchases and sales), the product images, the list of suppliers.

We're already on 10 and we haven't even used those products for anything (stocking, selling, invoicing, purchasing, etc, etc).

Reply on news.ycombinator.com