Hacker News Reader

Comment by bob1029 | Hacker News Reader

Thank you for this post. I read "10 Users: Split out the Database Layer" and about had an aneurysm.

I also work with fintech systems built upon .NET Core and have similar experiences regarding scaling of these solutions. You can get an incredible amount of throughput from a single box if you are careful with the technologies you use.

A single .NET Core web API process using Kestrel and whatever RDBMS (even SQLite) can absolutely devour requests in the <1 megabyte range. I would feel confident putting the largest customer we can imagine x10 on a single 16~32 core server for the solution we provide today. Obviously, if you are pushing any form of multimedia this starts to break down rapidly.

View on HN

As someone that uses Python and Django most of the time (a "slow" language), I haven't seen much in the way of performance problems at the application level. Usually some database optimization will do the trick.

Actually thinking about it- I have inherited plenty of performance problems at the application layer, but that's because the joins were effectively being done at the application level (and making huge numbers of database calls) when they should have been done at the database layer.

It seems like they recommend splitting out the database at the start because using a managed service is much easier than properly managing your own production database.

I can't speak for high performance/near or realtime system people but I would not trust a managed database service for those needs. My experience is that the managed offerings lag behind upstream versions substantially and usually are economical because they are multitenant. So you have a bit less predictability in io wait / cpu queue, lose host kernel level tunings (page sizes or hugepages, share memory allocation, etc), and - not naming names - some managed db services are so behind they lack critical query planner profiling features. That's not even going into application workload specific tuning for various nosql stores. This is a nice article but its audience is people that haven't scaled up a system but are trying to cope with success. It's not great generalized scaling advice.

All I will say is that our latency getting a business entity in or out of a SQLite database (running on top of NVMe flash) is on the order of tens to hundreds of microseconds. There will never be a hosted/cloud offering that can even remotely approach this without installing some "bring the cloud to you" appliance in your datacenter.

It almost kills me, just 10 years ago it was nearly six figures to get a RamSan that had 2TB storage and did 100k/25k r/w iops (https://www.networkworld.com/article/2268291/less-expensive-...)

Now a WD Blue NVMe does 95k/84k r/w iops at $215 and that's just off their website (https://shop.westerndigital.com/products/internal-drives/wd-..., may be more depending on shipping method...)

That said, it's not a fair comparison and I wouldn't want to run a big service on a single sqlite/nvme setup for more reasons than are worth mentioning, but not prematurely optimizing can take you really far - scale and money - with good design.

Those all sound like concerns that probably aren't your top priority when you have 10 users unless your product is performance critical, and then none of this guidance applies anyway. When you have 10 users, your database concerns are more likely to be: Is my database up? Is my database secured? Do I have automated backups? Am I otherwise at risk of losing data? Is the database fast enough for now to not be a blocker to my business? All of which are concerns that tend to be well covered by managed database services.

I think we also should be more clear with "10 Users". What does he/she mean? What do we mean?

It could be 10 users that each views a few web pages once every month or it could be 10 heavy users for an internal system that uses the system most of the working day and creates thousands of calls per user to the system each day.

It is as a lot of people have mentioned also very different with information that can be easily cached and things like monetary transactions where you don't want to see old data in reads and therefore often can't cache or use read replica db.

For systems with heavy users I have seen the need to use a few servers even with just 1000 - 2000 users. For a web system the same can happen if you have 1000 users active on the site at the same time (within a minute or so).

Reply on news.ycombinator.com