HN Explorer

Ask HN: How does big apps/platform manage between ORM vs. Stored procedures?

16 points by ameyv ↗ HN
I wanted to ask how does big app like (Uber/slack) or any other for that matter or platforms like github who use Ruby/Python/C#/Java handle CRUD operations at scale with ORM or Stored procedures.

Where do you draw the line when to use SP's or ORM? Considering not everyone understands database in depth and can write performant queries or SP's.

I know its very simple view and probably tons patterns (like CQRS) and infrastructure/serverless/geo-replicated architecture might be use behind the scene.

Have you ever worked on such systems where both ORM and SP's are used and how do they keep logic not fragmented at multiple places at scale?

TLDR; How highly scalable apps manage DB interactions in code vs handwritten SQL?

3 comments

[ 0.23 ms ] story [ 13.0 ms ] thread
Graffur
Very interested in the answers. I would guess that most big websites use stored procedures.
QueensGambit
When we were building a big app 10 years back, we used ORM for user facing modules and stored procedure for batch processing such as CSV import/export. We would clear the ORM cache for every SP run which are usually scheduled at mid-night to avoid stale data.

These days, it is graph DB (such as firebase) for user facing module. It syncs data into a warehouse (such as BigQuery) that we use for batch processing.

[dead] apolymath
I use Dapper in C# to access stored procedures and it's blazing fast. Unfortunately, most medium to large companies tend to use Entity Framework, which is a bloated beast of an ORM which sadly creates a void between a company's development team and database administrators, especially if the company decides to develop their database in Entity Framework using "code first" methodologies